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of the support packages, and the requirement for the user to 
become familiar with different models, concepts and 
vocabularies is a barrier to reaching higher effectiveness. 
The premise is that these common support systems have 
equivalent functions and a large intersection of operations 
that can be integrated. It is the purpose of this thesis to 
study a possible Integrated Application Software System 
(laSS) that will combine the needed capabilities into a 
functional system and present the user with a single data 
model and vocabulary set. The data model which is proposed 
for use by the IASS is the relational data model, since it 
is universally understandable, and has a robust theoretical 
foundation. 
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ABSTRACT 



AS Increasing data processing power becomes available at 
decreasing cost, greater numbers of nontechnical nersonnel 
are gaining access to automated systems that enhance their 
oroduct ivl ty , However, the sharp distinction between each 
0 * the sucDort nacicages, and the requirement for thp user to 
become familiar with different models, concents and 
vocabularies is a barrier to reaching hloher effectiveness. 
The oremise Is that these common supoort systems have 
egul valent functions and a large Intersection of operations 
t^at can be Integrated, It is the ourpose of this thesis to 
study a nossible Inteorated Aoolication Software Sv^tem 
(TASS) that will combine the needed capabilities i'^to a 
functional system and present the user with a single data 
model and vocabulary set. The data model which Is proposed 
for use by the TASS is the relational data model, since it 
Is universally understandable, and has a robust theoretical 
foundation , 
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INTRODUCTION 



The utilization of computers in many areas, such as 
personal computing or office and manufacturing automation, 
is rapidly expanding. No longer is their use being 
relegated to suoport personnel, but is soreading into the 
ran'rs of lo«er and middle level management. The malority of 
such users are non-computer orofes signals who are coming to 
depend on the computer to orovide a suonort capabilltY in 
the accomplishment of their Primary resoonslbllitles. 

Over the past years, numerous software packages have 
been made available to support a broad spectrum of users in 
varving environments. Capabilities such as word processing, 
database management, modeling, form generation, and 
electronic mall have become essential. The point to be made 
is that the original purpose of Introducing the computer was 
to increase the effectiveness and efficiency of the 
organization. While the present performance of each support 
package Is satisfactory, the manner in which they are 
oresented to the user is not. As Illustrated in Figure 1,1, 
each support system is tyoically disjoint from all others, 
and the user is presented with differing models, command 
vocabularies, and operating instructions. This non- 
integrated combination of application software requires a 
great deal of effort on the part of the user to become 
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familiar with a new system and remember it along with the 



other systems that are used. 
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Fiaure 1.1 - Dls-Jolnt Supoort Systems. 



What Is needed to increase productivity Is an integrated 
system that combines the caDabllitles of the suooort 
cacVcaoes Into a system ’which oresents the user with a 
slr.alp, yet easy, conceptual data model and vocabulary set. 
It Is such a system that is called an Integrated ^opiication 
Software System (TASS), and the ouroose of this thesis is to 
develop a design for its implementation. It is important to 
emphasize that the IASS is not built around the already 
existing application orograms, hut the reverse. Given an 
TASS's common user interface and concaptual level, the 
designer win evaluate each arollcation and design a new 
application program to capitalize on the Iass capabilities. 

The design objectives for the IASS are; 

(1) Fnsure a high degree of user friendliness and 
emphasize slmollclty. 
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(2) Minimize the initial and acquired user skill level 



necessary to qaln major functional use of the system, 

(3) Minimize the learning time required to gain 
functional use of the system, 

(4) Present a loolcal interface between each of the 
lASS's caoabilltles , but minimize the explicit user 
navigation between them, 

(5) Determine the largest intersection of functional 
caDabllltles for the individual apolicatlon oroorams and 
integrate them into a common conceptual level, 

(6) Develop as small a command vocabulary as possible 
at the user Interface, ensure that these commands form an 
intersection of the application program commands, and are 
consistent between each of the aoo 1 icat ions , 

(7) Eliminate the dependence on user proorammina in 
order to use tne system, 

(9) Embody the notion of software adaotlvlty whereby a 
user, already familiar with at least one application in the 
IASS, can learn a new application by studying only the small 
increment of new commands and functions that are specific to 
the new application, 

(?) New applications, not originally considered in the 
orlolnal IASS, are implemented by adding a small Increment 
of functions and commands to the TASS, 

(10) Allow for the interaction of the Included 
applications in support of each other. 
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While the IASS cannot be expected 



to completely 



integrate the separate features of each support package, it 
can strive to maximize the Intersection between them, Flaure 
1,2 shows a simple Illustration, In Venn Diagram form, of an 
IASS, 
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Figure 1,2 - IASS Support Package intersection. 



In the following chapters the basis of an TASS design 
will be discussed. Chanter 2 will describe a selected group 
of currently successful aDolication support programs that 
will be considered for integration into an IASS, Chapters 3 
and 4 will cover the conceptual level of the IASS which is 
invisible to the user. Chapter 3 discusses a common data 
object for the IASS, and Chapter 4 the conceptual level 
operations allowed on it. Chapter 5 covers the use of the 
conceptual level by the included application programs. 
Chapter 6 covers how the user win interface to the TASS, 
Finally, Chapter 7 presents the conclusions that can be made 
from this limited study of an IASS. 
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II, DESCRIPTION OF SUPPORT SYSTEMS 



In order to demonstrate tbe applicability of an 
Integrated Aoplicatlon Software System (IASS) and its 
conceotual level inteoration aporoach, six common software 
aoolications were selected. The apollcatlons were chosen 
based on their cerceived effect In supoortina an office 
based user, 

a. Text Editor 

b. Word Processor 

c» Relational Database Management System 

d. Electronic Soread Sheet 

e. Torms Generator 

f. Electronic ^ail 

As a non-in tearated collection of apollcation software, 
each of these pacW’ages is imolemented to accomplish a set of 
ooeratlnns on a specific file type, and the set of included 
operators is tailored for that type. Commands are not 
usually transferable between applications and the 

application vocabulary is verv "barooue” in that most of the 
operators exist as a matter of convenience to the user. Too 
often it is a very small percentaae of the overall 
vocabulary that is used over ninety oercent of the time. The 
majority of users only learn a subset of the vocabulary 
necessary to accomplish the essential functions of the 
aoplicatlon oac'<aae, and disregard the rest. 
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Representative commercially available soft'vare packages 
corresponding to the six selected application types were 
reviewed to determine the nature of the pertinent file types 
and the essential functions required of the application. The 
following sections will present the results of this review 
as they apply to each application package, 

4. T^XT EDITOR 

The purpose of a text editor is to prepare a text file 
In a*' appropriate form for use by a subsequent process, 
•’WORD STAR", and the "VT" and "EDIT" systems for UNIX were 
analyzed. These systems are described in Appendices (A), 
C?), and (C), 

The text editor can be divided Into five major 
functional categories of commands which are supported; 
<Create>, <Insert>, <Modlfy>, <Delete>, <Move>, and 
<Retr leve> , 

1 , Creation 

A facility used to define an empty file Into which 
the text will be entered. This Involves a directory entry 
of some tyoe, the allocation of storaoe space, and the 
creation of a buffer area, 

2 , Insertion 



Done 


an object at 


a time In 


relation to 


some 


referenced 


point in the 


text file. 


such 


as the 


cursor 


position , 


It Is possible 


to Insert 


any 


object 


at a 



12 



sceclfled ooint. Insertion is non-destructive in that the 
object is Inserted between exlstino contents, without 
overwritinq. The object to be inserted may be entered by 
the user, come from a buffer, or come from another file, 

3, Modification 

In relation to some referenced point in the text 
file the current contents are altered , Modification is 
destructive In that the current contents are destroyed by 
writinq over them. Global modification is oossible, 

4, Deletion 

In relation to some referenced point in the text 
file an object of any oranulartty level is removed. Global 
deletion is oossible, 

5 , Movement 

The current ooint of reference in the text file is 
chanaed to me^t the desires of the user. Control of 
movement Is oossible at any object level. The user should 
have the capability to move to a predefined location or to a 
location that meets some condition, 

6 , Retrieval 

While not directly resoonsive to user retrieval 
commands, the text editor supoorts the user by displaying 
the local area around the point of reference, in a general 
sense this is a desired retrieval of text from the file. 
Retrieval is automatically done for the user when the point 
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of reference changes to ensure the user can establish the 



context of the nolnt of reference, 

B. WORD PROCESSOR 

Files prepared by a text editor can be processed by a 
Word Processor (WP), «woPD STAR", an on-line WP, and "NROFF 
-ME", a WD for the Unix ooeratlno system, were analyzed. 
These two systems are described in Aboendices (A) and CO). 

Currently there are two aooroaches to word orocesslna: 

(1) Off-Line Formatting. In addition, to the actual 
text In the edited file, a combination of soeclal 
characters, and characters strings, can be embedded in the 
text file for use by the wp. These soeclal embedded 
character strings are commands used by the word orocessor to 
produce the desired Printed format of the text file. This 
reoulres a two step procedure bv the user. The user first 
visualizes the desired format of the outout and then 
translates it Into a combination of the actual text and the 
embedded WP commands. The text file is then Processed by 
the WP, This Is a level of indirection that delays feedbac'c 
to the user as to the effect of a command, 

(2) On-Line Formatting. In this case, while most 
of the WP commands are still embedded In the text file, they 
are immediately executed. As the user inputs the text, it is 
displayed on the screen in the desired format. The user 
thereby receives immediate feedbacx as to the effect of 
formattlno commands. However, the problem of the dlsolay 
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format being bigger than the display dimensions is a 
problem, if only a minor one. 

The WP, unlike the other application packages, does not 
directly manipulate a data object in the course of Its 
operation. Instead, it intercepts a stream of data from the 
data object and alters the display format prior to output. 
For this reason is seems loolcal to consider the wp to be a 
oart of the editor - the aociicatlon package that 
manipulates the data object upon which the wp deoends. 

C. OATAPaSE 'MANAGEMENT SYSTEM 

Data is slmcly symbols which are stored, Tn and of 
itself, a datum has no significance. However, when coupled 
to an entity, the class of a datum becomes an attribute of 
t*'e entity and the value of the datum can be used as 
Information to describe an Instance of the entity. When 
data Is stored in a comouter It is known as a database. To 
transform the raw data into an abstraction suitable for a 
person to use and/or modify is the major function of a 
Database Management System (DRMS), In a sense a DBMS acts 
as an interpreter between the user and the computer. It 
interprets user statements describing what is to be done 
with the database into the lower level algorithms necessary 
to perform the operation on the conceotuai and eventually 
the Physical representation of the data in the computer. 
From the oersoectlve of the computer, the D9MS translates 
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the physical implementation of the data throuqh the 
conceptual representation to the appropriate user view, in 
this way the DBMS provides two levels of data independence. 
Data independence implies that modification can be made to 
the implementation of the data without affectlna the loolc 
of the application oroprams. Data independence between the 
conceptual schema and its ohysical implementation allows 
changes to the ohysical implementation of the conceptual 
schema while oermlttino aoolication programs to run as if no 
change had occurred. Similarly, data Independence between 
the conceptual schema and a user view allows changes to be 
made to f^e conceptual schema while permlttlna aoolication 
oroorams to run as if no chanoe had occurred. 

In addition to the data management function, a DBMS also 
provides functlc^s to ensure system integrity. Towards this 
end a DBMS enforces database security constraints. The 
security facility ensures that unauthorized access to data 
Is not allowed, A DBMS typically ensures that the reoulred 
properties of data are guaranteed. These properties can be 
either syntactic, that is structural, or semantic, for 
Instance contained within a specified domain, A DBMS 
typically provides a mechanism to protect the database from 
a system crash by regularly making back-uo cooles of the 
database. In the event of a system crash, a obms tyolcally 
provides a facility to restore the database to a previously 
consistent state. Finally, in a multi-user environment, a 
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DBMS typically provides a synchronization mechanise to 
protect the database from inconsistencies which might result 
from simultaneous access to a database, especially if one 
access entails a change to a shared data item, 

"DBASE TI" and "SEQUITUP" were reviewed as 
representative relational data base models and are described 
in Appendices (E) and (E). A relational DBMS was selected 
as an IASS conceptual database model due to its familiar and 
universally understood data object, the relational table. 
T^e basic organizational unit in the relational table is the 
named and domained field, A record of arlty "n” in the 
relational table contains n fields, each containing a value 
from its domain. A relational table is the next higher 
level of orcanizational abstraction. The overall schema of 
the relational table Is defined bv onysical properties of 
the fields and embodies the relationship which is defined by 
the field set. 

A DBMS can be logically divided into three functional 
Darts - data definition, data manipulation, and query 
retrieval. These parts can be further refined into the 
functional operators <Create>, <Insert>, <Modlfy>, <Deiete>, 
<Move>, and <9etrleve>, 

I • Creation 

The existence of a relational table is typically due 
to a need perceived by the user to organize data. Creation 
is therefore the orocess by which the relational table is 
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defined in a database bv its identity and composition. The 
existence of the table is noted in some form of a database 
table directory. The composition of the table defines the 
schema of the relational table . Modification of a user 
defined table can be viewed as a special case of creation or 
re-creation. A table name can either be changed or the 
schema redefined. In addition to these explicit methods of 
creatlno relational tables, imoilcit methods also exist. As 
a result of the relational operation JOIN, a new relational 
table can be created. The method of nanina the new 
relational table is imolementatlon sceclfic. The composition 
of the table, however, is derived from the schema of the 
operand relational tables. 

2. Insertion 

Insert is a comconent of the set of data 
manipulation operators. The action of an insert is to place 
a record into the relational table. The orloin of the record 
to be inserted is irrelevant to the operation. The effect of 
the operation is that a new relational table is derived from 
the old relational table, order not belna sloniflcant, 

3 . Modification 

■Modify is a component of the set of data 
manipulation operators. The action of a modify is to change 
the data in a field. DBMS's tyolcally do not restrict the 
origin of the new data to wbat the user supplies at a 



18 



terminal but can be as a result of evaluation of expressions 
or derived from other relations In the database, 

4 . Deletion 

Delete Is a component of the set of data 
manipulation operators and Is In fact the Inverse operation 
of Insert. The action of delete is to remove a record from 
the relational table, the final disposition of the deleted 
record Is Immaterial to the operation, 4 delete operation is 
typically a two step process. A record Is first marked for 
deletion and then explicitly removed from the table, 

5 , Movement 

The movement operator can be viewed either as a 
passive data manipulation ooerator or a querv retrieval 
operator, ‘■Movement encompasses the process of cnancinq the 
current point of reference In the database. The ultimate 
destination is determined from manlou latino data in the 
database or as a direct result of a ouery on the database. 
The Dolnt of reference can be of any oroanizatlonal 
abstraction from an entire relation to an individual 
character In a field. This range In movement implies that 
this ooerator subsumes the theoretical relational alcebra 
ooerators PROJECTIOM and SELECTTO^\ Movement is a reoulred 
ooerator In order to scan and extract Information from, or 
in conjunction with, the performance of any of the other 
operations on the database. 
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6, Retrieval 



Retrieve is exclusively a auery resoonse operator. 
The condition of a query specifies the infor-nation to be 
extracted or derived from a database. A auery can be in 
many forms. Traditionally a ouery facility is embodied In a 
soeciallzed lanauage which the user emolovs to extract 
information from the database. In this simplest form, a 
query is equivalent to the relational algebra PPQJEICTION 
operator possibly following the SELECTION operation on the 
referenced relation. Queries can exist in subtler forms. 
Movement through a database can actually be the result of an 
underlying, implicit retrieve operation. Some uses of forms 
embodv a retrieval operation as they extract information 
from a database to derive its contents, Peoorts also embody 
the retrieve operator in the same way as a form. From the 
database, information is retrieved and displayed in a user 
specified format, 

D, ELECTRONIC SPREAD-SHEET 

An Electronic Spread-Sheet pacKage provides an Important 
numerical modeling capability to the user. This application 
provides the user with a piece of "electronic" scratch cap er 
for doing fairly complicated numerical problems, and models 
that are of a recurring nature. Instead of reaching for 
pencil, paper, and calculator each time, the user will call 
the electronic spread sheet and by entering the needed 
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values cause the spread-sheet to complete the 
calculation/model. It comDllments the inclusion of the word 
orocessor and database manaoement system In the IASS. The 
commercially available "VISICALC" system was reviewed, and 
is described In Appendix (G), 

Spread-sheets are commonly divided into addressable 
(row,column1 entry positions, similar to a checicerboard , and 
are used to graphically dlsolay numerical data in a tabular 
format. A small portion of the soread-sheet is usually 
visible on the screen at any one time and the user must use 
window and screen commands to move across the entire sheet. 
Each entry position is an independent entity and can contain 
any of the data tyoes - character, numeric, or function. 
The consents of an entry position can be expressed in 
relation tvo the value of a previous entrv oosltlon. 

System ooerat ions consist of <Create>, <Insert>, 
<Modlfy>, <Move>, <Delete>, and <Retrleve>. 

1 . Create 

The user initializes a data storage structure for a 
new spread-sheet. The dimensions for the new spread-sheet 
are initialized and all entry positions are set to null 
values . 

2 . Insertion 

Given an already existing spread-sheet, the user 
adds a new column or row to the soread-sheet at an Indicated 
location. This enlarges one of the spread-sheet dimensions 
by one. 
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3, Modification 



Change the current value in an existing entry 
position to a new value or function, 

4, Deletion 

Given an already exlstlna spread-sheet, the user 
deletes an entire column or row from the spread-sheet at an 
indicated location. This will reduce one of the soread- 
sheet dimensions by one. 

5 , Movement 

Allows the user to view the contents of the entire 
spread-sheet through the limited dimensions of t^e screen 
display by permitting the user to maneuver the screen across 
the sbread-sheet . 

6 , Retrieval 

The tabular dlsolay of the soread-sneet on the 
user's screen is the result of a bredefined retrieval from 
the stored representation. As changes are made to entry 
positions and they, in turn, effect other entry positions, 
the tabular disnlay is ’<ept updated by automatic retrievals. 
Additionally as the user moves, or alters, tne window into 
the spread sheet new information must be retrieved to meet 
the changed request. The user cannot specifically ask for 
information from the system, but instead accepts the single 
retrieval the soread-sheet package was d<»signed to 

automatically produce. 
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E, FORMS GENERATOR 



By definition, a "form" is a printed document with 
blanks to be filled in, and "format" is the arrangement, or 
plan, of a presentation. Traditionally, a document is 
assumed to be a piece of oaoer, and the incut device used to 
Dlace values onto the document is the human. 

In the Electronic Data Processlno (EDP) environment, 
these notions are generalized to where a document can also 
oe derived from, or stored into, a database or data file. 
Regardless of the semantic general izat ions Introduced by 
EDP, the looical view of a form, as well as its function, 
remain the same, A form is used as a template to disolay 
information and/or collect a set of data, A form is 
distinguishable from a reoort in that a form recresents only 
one imsi-ance, or a coalescence, of a set of data elements. 
The reoort contains the form as a special case, hut reoeats 
it for each instance in the set of data elements, 

A Form Generator is a utility to assist the user in 
designing a dlsplayable form at "design-time" and emoloyinc 
it at "use-time". Since creation and use times are 
different, the design-time disolay must reoresent the use- 
time disolay of the form as closely as possible. From the 
design the Form Generator must translate the visual 
soecif icatlons into the appropriate representation for use 
by the display function at use-time. In addition to the 
physical layout of the displayed form, the design and 
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internal representation must contain information regarding 
the value association or derivation at use-time. The DBASE 
II form generation facility, and the separate "ZIP" screen 
oriented form generator were evaluated and are discussed in 
Appendix (H), 

The design-time environment includes both initial form 
design and deslon modification. Form design is done by use 
of an editor and an on-screen caoabliity is essential to 
achieve deslon-tlme and use-time visual proximity. The 
editor could be an integral oart of the form Generator or 
separate. Value association is not done by the form 
generator directly. The user states the value association 
of a "blocK" in terms of the use-time function which must 
evaluate the "blocX" values. 

The orocess of form generation entails describing both 
the display features of a "blocX" in the form and the use- 
time association. The functional list of ooerators to 
support a form generator are <Create>, <lnsert>, <Modify>, 
<Delete>, <Move>, and <Retriave>, 

1 , Creation 

Creating a new form entails naming the form and 
maxing it Xnown to the rest of the system for use. Only the 
empty structure is created and will reguire the user to 
enter information into it. 
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2, Insertion 



The user adds a new "blocvc" to the form by 
specifying Its character istlcs . Characteristics may be - 

position, prompt, Inout/output , type, and processing 

Information. A grouplno of these "blocks” win naKe a form. 
Actual "blocic" specification and addition Is done through a 
level of Indirection where the user draws the '‘blocktsl" on 
the screen and the system determines the carameters 

necessary to mav-e the form. 

3 . Modification 

The user changes one or more of the characteristics 
of an already existing ”bloc)c". 

4. Deletion 

The user removes an entire "biocK" from the form, 

5 . Movement 

The user has a oolnt of reference within the alven 
form. At any given time some "bioCc" is the oolnt of 
reference, and commands are available for the user to move 
this oolnt of reference, 

6 . Retrieval 

The user desires to see the format In which the form 
will be displayed both at design-time and run-time. The 
retrieval operation Is automatic and translates the 
Information stored In the form's structure Into the 
appropriate display. Actual deslan and modification of a 
form is done on this display and the form generator 
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determines the additional information it will need to 



recreate the finished form on demand, 

F. ELECTRONIC MAIL 

Electronic ”all is a facility for sending messages from 
one user to another. The ”matL" system used by the UNIX 
ooerat ing system was reviewed and a descrlotlon Is given in 
^poendix ( I ) . 

An Electronic Mail system uses a orede fined mess aae form 
which contains information, such as destination, subject, 
and main body. Once created, the messaoe is sent to the 
destination where it is placed in a message file, called a 
"mailbox'’, for readino. The major functional ooerations in 
a mall system are <Create>, <Irsert>, <’'^odlfv>, <Delete>, 
<Movement>, and <Retrleval>, 

1 . Creation 

The system oenerates an empty message form which the 
user fills in, 

2 . Insertion 

Messages are inserted into the various mailboxes 
that the mail system maintains, A message is sent to 
another user by storing it in the system mailbox, 

3 . Modification 

Messages are initially created with no values in the 
message form. Composing a message therefore, entails making 
modifications to the null carts of the message. 
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Modifications can also be made to a messaqe any time during 
composition, before sending it to its destination. Finally, 
fields in a message may be modified by the recioient, in 
order to retransmit the messaoe, 

4. Deletion 

BY reviewlno messages from the system mailbox, they 
are deleted from the system mailbox and placed into a local 
area. The user may delete messaaes from the system or local 
mailboxes at any time, 

5 , Movement 

All the previous commands are performed in relation 
to a Point of reference. The point of reference in a 
mailbox can be changed by the user in order to browse 
through the messages, or edit them, 

5 . Retrieval 

Reading a messaoe is done by retrieving the contents 
of the message fields and displaying them to the user. 

In review, Chapter 2 has shown that a general 
commonality exists between the functions of the given 
applications. This commonality has been presented as the set 
of six command categories - <Create>, <lnsert>, <Modlfy>, 
<Delete>, <Move>, and <Retrleve>, The following chapters 
will lead to an integration based on this commonality. 
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Ill, THE COMMON DATA OBJECT 



The Key to achlevlna an Intearated system which can 
support formatted and unformatted data is to map the looical 
file types associated with the aooiications , Into one 
conceotual data object, mnis conceptual data object is then 
oart of a model of the apolicatlons and their use. The 
functional intersection of oneratlons on the files can be 
Implemented by a sinale set of orlmltlve conceotual 
ooeratlons on the common data object. 

The TASS must represent each of the loqlcal file tyoes 
associated with the included apclications in such a way as 
to support the essential functions of each aDOllcation. The 
data object chose^ for this IASS deston is the table. The 
table is a natural method of oroanlzlna data and therefore 
should be understandable, even by naive users, A table is a 
two dimensional array contalnlna rows and columns. The IASS 
uses the table to reoresent a "real-world'* entity. Each 
column represents one attribute of that entity and each row 
represents a unique occurrence of an entity. A table is 
almost equivalent to a relational database relation, exceot 
that a table implies that rows and columns have an order in 
the table which can be used in a oosltional addresslnc 
scheme. Since addresslnq is associative in a relation, the 
table must Include columns which represent Kev values to 
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uniquely Identify each row. With this slight modification, 
any datum in a table can be accessed by specifying the name 
of the table, the value of the key, and the name of the 
attribute containing the datum. Hereafter, the common data 
object will be referred to as a relational table. Rows of 
such tables are usually referred to as "tuoles" and columns 
are referred to as "attributes". The assumotions to be made 
concernlno the relational table in this thesis are; (1) Row 
or column order is not sloniflcant, (25 ^^11 columns are 
named and must be unique within the table, and (35 Each row 
is uniquely identifiable by a key value. 

In the following sections each logical file tyce will be 
described as a relational table. The attributes of each 
table tyoe were selected based uoon its perceived orimary 
use, a.s such, the set of attributes associated with each 
table was determined in order to orovlde the Information 
necessary to suoport that orimary aooiicatlon. These tables 
are merely special cases of a relational database table. 
Based on their predef iniclon , their use can be bounded 
within the primary apolicatlon and therefore can be "tvped". 
To be of a certain type, it is sufficient that the table 
contains the minimum set of attributes necessary for that 
soeclfic type as a subset of its total set of attributes, 
(e.o. A given system table might have five attributes. Three 
of those are the required attributes for a tyoe-1 
application table. The remalnlno two attributes could be the 
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required attributes for a type-2 table,) This itiiDlles that, 
as an Implementation Issue, a sinale table could be 
considered to have multiple types, but for simplicity let us 
assume that a table will have only one type. As 
applications are added to the IASS, the accomoanylno minimal 
set of attributes must be defined to represent the new table 
tvoe. There are many structural oroanlzatlons which could 
reoresent a loqlcal file tvoe. The final decision on the 
oroanization of the table must be made to maximize the use 
of the conceptual level operations that are available to 
manipulate the data In the table. These conceptual level 
operations will be covered in Chanter 4. It is Important to 
note that the table Is a structural oroanlzatlon used as a 
model and therefore problems may arise in express! no the 
actual aopllcatlons by the table model. 

A. TEXT 

Text, as data in a text file. Is a "continuous" string 
of Individual characters from some character set Ce.g, 
ASCII), The use of text as data Is by character, where each 
character Is a unit of data used in an aoDllcatlon, 

Objects such as words, sentences, lines, or oaraqraohs 
are loqlcal abstractions, hidden in the text, that are 
useful as Information only to a human user. Any IASS 
manipulation that may alter this hidden logical abstraction 
will directly effect the ability of the IASS to transform 
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the data back into information, (e.o. deletinq every other 
word.) This will require the imposition of limitations on 
the use of table ooerators on the text table in order to 
protect this logical abstraction, (i.e. operations incapable 
of taking into account the logical abstraction of text will 
not be used.) 

The only naturally occurring data elements in a text 
file is the single character, and the entire character 
stream. Their domain is all the elements in the aoplicable 
character set. These two orohiems, the continuous nature of 
text and its discreteness being limited to a single 
character or the entire file, make the text file the most 
difficult file type to model as a relational table. The 
table must quantize the continuous text stream Into column 
units, thus destrnylna the continuity of the text. 
Additionally, while the relational table ooerators recognize 
the column as being an object. In fact it has no natural 
occurrence in the text file. Any definition of a column 
which represents text objects between the single character 
and the entire text file, is an arbitrary quantization of 
the text stream. Figure 3,1 illustrates the problem by 
arbitrarily choosing a column size ecual to ten characters 
(the character represents a carriage return and llna 
feed). This division of the text stream into units, for use 
as tuples in a table, has no corresponding unit in the 
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orlqinal text file, and nas imoosed structural limitations 
by the column boundaries. 



Ca) Text Stream 

MR, JOHN SMITHR1349 WILMINGTON DR.9CARSON, CA 
(b) Tuole Representation 
MR. JOHN s 
MITHai34q 
WILMINGTON 



DR.^CARSO 




Figure 3,1 - Text Representation Problem 



This problem of using a ”dlscrete'’ renresentatlon will 
have to be acknowledged and steos taken at the a do 11 cat ion 
level to ensure t^e limitations imposed by the problem are 
not violated. In determining the size of a text tuple, 
neither the single character nor the entire file are 
acceotable units to be used in the relational table model 
since they would require a large amount of processing by the 
application level to transform them into usable units, (The 
aroument is similar to memory manaoement questions of oaglng 
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versus segmentation and how large each unit should be.) Some 
arbitrary size, between the two extremes, will have to be 
chosen during implementation. For now it is assumed that the 
size limit exists. 

The text file can be conceptually viewed as a text 
table, as in Figure 3,2. The text stream Is reoresented by 
the set of rows in the table. Each "contents" column is 
densely nacxed In that no unused space Is left in any row, 
exceot the very last row in the table. The text table does 
not match in ary wav the oerceived "display" of the text 
file, as shown in Figure 3.1. The display structure Cline- 
oriented, screen-oriented, or whatever) is considered an 
application level Issue and win be covered there. Each row 
In the text table has a unioue seouence number, "id", to 
rnarkr the relative position of its contents in the text 
stream , 



Id contents 

line-1 I 

I 

line-2 I 



line-n I 

1 ** 

Figure 3.2 - Text Table 
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B, DATABASE 



A relation In a relational database is described as a 
table, as shown in Figure 3,3. Relational database tuples 
are represented as the rows of a table and the attributes as 
the columns. The description of an attribute is defined by 
the user, and the set of attributes define the modifiable 
structure of the relation table. Chanter 1, Section (C) 
covers the concents behind the relational DBf^S in greater 
detail. 



Id atr-1 atr-2 atr-n 

tuple-1 
tuole-2 



tuple-n 



I 

I 

I 

j 

! 

I 

I 

i 



Figure 3,3 - Relation Table 



C. SPREAD-SHEET 

A spread-sheet is a database used as a numerical model 
In a oredeflned tabular dlsnlav format, A spread-sheet can 
be represented as a collection of entry position tuples in a 
table, as shown in Figure 3,4, Each row in the table 
represents a single entry oosltion in the spread-sheet. The 
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table columns reoresent the predetermined elements necessary 
to describe the entry position, such as the location, value, 
and function. 



id location value function 

Dosltion-1 I ! I “ I 

«- 1 I I .. -.1 

DOS i t ion-2 • I I ' 



posltion-n I I I 

I If** 

Flcfure 3,4 - Spread Sheet Table 



D. FORM 

A form is a template throuch which input and output 
values are transmitted. The information stored in a form 
database is used to preoar e the visual image of the template 
in a user specified format. 

The basic subunit of the form is called a "blocK", and 
it represents a basic unit of data for the form. The easiest 
way to visualize a "blocV:'* is to consider the Internal 
Revenue Service 1040 Tax Form. It is used as an Inout form, 
and each entry has a corresoondlna number to Identify it as 
a separate entity, or "blocX", Each of these "blocks" has 
an a oosition on the form, an identifylno number, a prompt. 
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and space for an entry of some type. This means that the 
form table must Include positional data for the block as 
well as data to determine how the block is to be used for 
specific applications, 

A form can be represented as a collection of tuples 
contained in a table, as shown in Floure 3,5, Each row in 
the table represents a slnple "block" on the form and 
contains a description of the "block". The columns of the 
table are the predefined attributes of a block - unioue ID, 
screen location, prompt string, Input or outout Identifier# 
and the functional use of the block. Each table column 
represents an element of that descriotion. 

id location oromot l/o function 

block-1 I I I I ~ "i j— — 

i I I I I 

block-2 I I I I I 



block-n I I 

I I 

Figure 3.5 - Form Table 



The "id" is a unlaue identifier for the block and would 
be system controlled, "Location" soeclfles the startino 
oositlon for the "block" on the form. If reoulred, a 
"oromot" string could be Included to indicate the ouroose of 
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the entry position on the form (e.a. Name, Address, Number 
of exemptions, etc,). The "l/o" field will tell the Form 
Generator how to interpret the "function" field. The exact 
use of the "i/o" field Is implementation dependent, but some 
obvious entries are "input", "outout", and "text". Lastly, 
the "function" field will contain a command string for the 
block. If it is an Inrut block, then the "function" field 
might contain the location where the user entered value is 
to be stored. If it is an output block, it might contain a 
query to be made on a database. If it is a text block, it 
mlaht contain the name of the text file that is to be 
Inserted in the form. As can be clearly seen, the actual 
use of the form table will be verv Imolementatlon dependent 
and such Issues will not be directly addressed in this 
thesis. 

E. ELECTRONIC MAIL 

Electronic Mall is a preformatted message sent to 
another user. Data contained in a message can be used as 
information to determine addressee and subject associated 
with a message. The data In a message Is manipulated 
tyblcaily in the course of an editing session or by an 
application program to output a message to be read by the 
recipient, A "mailbox" can contain any number of messages. 
Each message contains a unloue ID number, heading, and body. 
The ID attribute is a unloue Identifier of a messaoe in a 
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mailbox, Tbe domain of the ID attribute is all unlaue 
Identifiers as defined in the system. The ID could be local 
to a mailbox, or be of a global nature. The body of the 
message is textual and its domain is a continuous stream of 
characters or a reference to a text file. Heading consists 
of an originator, recipient, date, and subject , The 
originator, recipient, and subject are character strings of 
some maximum length. The date is some allowable value as 
determined bv the date convention used by the system. Each 
message tuple Is a complete message being routed from a 
sender to a recelver(s). 



id from to date subj bodv 

mso-1 I I " I I 

I U- I I 

msa-2 II II 



msa-n I I 

I I 

Figure 3,6 - Mailbox Table 




The mail file can be represented as a collection of mail 
tuples contained in a table, as shown in Figure 3,6, A 
"mailbox" is a table with the rows reoresentina individual 
messages and the columns representing the predetermined 
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format of the message, such as from, to, date, subject, and 
main body. 

This will end the discussion of representing the logical 
file tyoes as a single conceptual data object in the form of 
a relational table. This chapter has shown that each of the 
five logical file types can be mapped Into a table format 
with varying decrees of success, A "secret" that will be 
possessed by the aeoll cation level is just how successful 
this maooing was. Of the oresentiy included file types only 
the text type has shown slons of major problems. However, 
similar situations could occur as new applications are added 
to the IASS, The solution to the oroblem is to accomplish at 
the apo Heat ion level what cannot be done at the conceptual 
level due to the modeling limitations. The next charter, 
Chapter 4, win cover the conceptual level operations that 
are available to manloulate the common data object tables. 
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IV. OPERATIONAL INTERSECTION 



A major concept behind the Integrated Application 



Software System 


Is 


the 


existence 


of a 


comrron 


"conceptual 


level" that is 


used 


by 


all 


the 


included 


application 


programs. It 


Is 


important 


to 


note 


that 


It is the 



acolication programs, and net the user, that “111 interface 
with the conceptual level. 



"aPPLICATION LEVEL" 



"CONCEPTUAL LEVEL" 



I PRIMITIVE I 
I OPERATIONS I 
! I 



I COMMON I 

I DATA I 

I OBJECT I 

I I 



Figure 4,l - lASS Conceptual Level, 

This conceptual level will manage the data in the common 
data object, described In Chapter 3, A set of primitive, or 
basic, operations designed to manipulate the common data 
object and enforce integrity constraints will be included at 
this level. Figure 4,1 Illustrates the conceptual level. 
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The aopllcation packages will call these operations to 
perform desired manloulations at the conceptual level In 
support of the user. The specific application determines 
the combination of primitive operations necessary to 
retrieve data from the data tables in conformance with the 
use of the table as a model of the apoilcation. Only those 
operations that cannot be accomplished at the conceptual 
level, due to modelino failures, need be included in the 
application level, 

A, BASIC OPERATIONS 

The set of table primitive operations is the source of a 
major IASS operational Intersection, All applications 
attached to the IASS can tjse these commands in order to 
perform their function. However, as modeling problems will 
exist, each application area may have limits that make a 
certain operation meaninaless. 

Since the common data object is a relational table, tne 
natural set of primitive operations are the basic table 
manipulation operations inherent from relational database 
theory. The operations are named; INSERTION, MODIFICATION, 



DELETION, 


projection, selection 


, UNION, 


SET 


DIFFERENCE, 


cartesian 


PRODUCT, TMTERSECTIGN, 


OUOTIENT, 


JOIN, 


and NATURAL 


JOIN, These operations are set 


theoretic 


in 


that their 



operands are tables Csets of tuoles) and their results are 
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tables. This feature of the relational ooerators eliminates 
the need for any application to be concerned with iteration 
control. These operators are divided into two arouos, Unary 
and Binary, based on the number of operands reaulred, 

1 , Unary Table Operations 

The first five operators are unary operators in that 
they use a slnple table ocerand. The operators are; 

a. Insertion 

Given a relation R, INSERTION adds a new tuole 
to R at a specified, or default, location, 

b. Modification 

Given a relation R, MODIFICATION chances one, or 
more, of the components of a tuple, or tuoies, in the 
relation R, 

c. Deletion 

Given a relation R, DELETION removes a tuole, or 
tuples, from the relation R, 

d. Prolectlon 

Given a relation R of arity "a", a PROJECTION of 
R is a relation formed by removina some of the components of 
R and/or rearranqlnq some of the remalnlnq components. 

e. Selection 

Given a relation R, a SELECTION on R is the set 
of tuoies in R that make true some conditional statement 
based on the components of R, The operands of the 
conditional statement are constants or the components of R. 
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The operations of the conditional statement are 



the 



arithmetic comparison operators - less than, equal to, 
greater than, less than or equal to, greater than or equal 
to, and not equal to - and the logical operators - AND, OR, 
and NOT, 

2 , Binary Table Operators 

The seven binary operators win use two tables as 
operands. A description of the seven operators follows and 
for help In understanding them, some examples will be given. 
For that purpose two ’’representative relations” are given In 
Figure 4,1 for use In each of the descriptions and examples. 



A 


a 


C 


a 


b 


c 


d 


a 


f 


c 


b 


d 



Relation "R" 
Figure 4,1 - Initial 




Relation ”S” 
relational tables. 



a. Union 

Given two relations, R and S, the UNION of R and 
S are those tuoles that are in R, or S, or both. The UNION 
operation is denoted by (R u S), and Figure 4,2 shows the 
results. Both tables must be of the same arlty, and an 
attribute in the first table must be matched by the same 
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attribute In the second table, (l.e. In this case 0 = A, E 
= B, and F = C.) 



A 


B 


C 


a 


b 


c 


d 


a 


f 


c 


b 


d 


b 


g 


a 









Figure 4.2 - Result of (R U S). 



b. Set Difference 

Given two relations, R and S, the SET DIFFERENCE 
of R and S is the set of tuples that are in R, but not in S, 



SET DIFFERENCE is 


denoted (R - 


S) 


, and 


S'! dure 


4,3 shows 


the 


results , 


Both 


tables must 


be 


of 


the same 


arity, and an 


attribute 


in the 


first table must 


be 


matched 


by the 


same 


attribute 


in the 


second table 


• 


(l.e. 


in this 


case 0 = 


A , E 



= B , and F = C, ) 



A 


B 


C 


a 


b 


c 


c 


b 


d 



Figure 4,3 - Result of (R - S). 
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c. Cartesian Product 

Given two relations, R of arlty "al" and S of 
arity ”a2'’, the CARTESIiN PRODUCT of R and S is the set of 
tuples of arity "Cal + a2)" whose first al components form a 
tuple In R and whose last a2 components form a tuple in S, 
cartesian product is denoted by (P X S), and Flqure 4.4 
shows the results, Each of the resulting attributes of the 
CARTESIAN PRODUCT operation must be unique. 



A 


B 


C 


D 


E 


F 


a 


b 


C 


b 


g 


a 


a 


b 


c 


d 


a 


f 


d 


a 


i 


b 


a 


a 


d 


a 


f 


d 


a 


s 

i. 


c 


b 


d 


b 


g 


a 


c 


b 


d 




a 


f 



Figure 4.4 - Result of (R x S), 



d. Intersection 

Given two relations, R and S, the INTERSECTION 
of R and s is the set of tuples that are in both R and S, 
not those that only occur in one relation, Intersectiqm is 
a shorthand for R - CR • S), is denoted by (PA S), and 
Figure 4,5 shows the results, Roth tables must be of the 
same arity , and an attribute in the first table must be 
matched by the same attribute in the second table. (l.e, in 
this case D = A, E = B, and F = C,) 
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A 


8 


c 


d 


a 


f 



Figure 4,5 - Result of (R A S), 



e. Quotient 

Given two relations, X of arlty "al” and Y of 
arity "a2" wnere al is oreater than a2 and there is at least 
one tuple in S, the QUOTIENT of X and Y is the relation of 
arity Cal - a2) composed hy; First tal<e the PROJFCTinM of X 
over the first (Kl-)c2) comoonents and call the resulting 
relation T; Second, ta><e t^'e CARTESIAM oROniJCT of T and Y 
and call the resulting relation U, Lastly, determine the SFT 
DTFFFPFNCF between U and X. 
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f 
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Relation Y 
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f 
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e 




A 
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Relation X 
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tX ▼ YD 



Figure 4,6 - Result of (X r YD, 
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QUOTIENT is denoted by fX t and Figure 4,6 gives sample 
X and Y relations, and the result of CX r Y), 
f. Join 

Given two relations, R of arlty "ai" and Z of 
arlty "a2’’, the result of a JOIN would be a relation of 
arlty (al + a2) containing those tuoies in the CARTESIAN 
PRODUCT of R and Z where a component in R stands In some 

relation to a comconent in Z, a JOIN is denoted by R iXl Z, 

» 

and FI cure 4,7 shows a sample relation Z and the results of 

(R IXI Z). 
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Relation Z CR 1X1 Z) 

8=D 

Figure 4,7 - Result of (R 1X1 2), 

8 = D 

g. Natural Join 

Given two relations, R of arlty "al" and u of 
arlty "aZ" where R and U have "cl" attribute names in 
common, the result of a NATURAL JOIN is a relation of arlty 
(al + a2 - cl) formed by taking the CARTESIAN PRODUCT of R 
and U, then performing a SELECTION based on the equality of 
the common attributes in the tuples, and lastly performing a 
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1 A A 



PROJECTION with all possible attributes listed once, NATURAL 



JOIN is denoted by (RlXlU), and Figure 4.8 shows a samole 
relation u and the results of (POOU), 
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Relation u ( R iXl U ) 

Figure 4,9 - Results of (RIXIU). 



3, SUITABILITY OF OPERATIONS 

Lcokclnq at the conceptual data object as the relational 
table, and given the list of ooerattons fro'n section (A), 
above, it should be obvious that any ooeration, or series of 
operations, performed on a taole will produce a 
theoretically useful relational table for some aoplicatlon. 
It will have a valid table structure and therefore can be 
manloulated by any operator. There are an inflnit** nunber 
of manipulation possibilities which can result in a endless 
speculation of apollcatlons , The conceptual view of the 
table and Its operators only takes on sioniflcance when 
bounded by some application. It is the application that 
gives meaning to the usefulness or unsuitability of some 
ooeration or series of operations. Therefore, the Intention 
of this section is to measure the usefulness of the basic 



relational operations within the functional scope implied by 
the selected set of aopllcations data types described in 
Chapter 3, 

Before describlnq each of the operations it is Important 
to define some of the descriptive words that will be used 
for the operations: 

Table Structure - the number of attributes, or fields, 
the table contains and the characteristics of each (name, 
type, size), 

syntactical ly Correct - the results of the operation is 
within the bounds of the operation definitions presented in 
Section (^) above. There are two subsets of this 
descr lotor : 

Meanincful Result - The result of the operation will 
be a table with an identified s**t of attributes and in all 
probability , at least one tuple. The resulting table will 
have the same structure as the oriainal table, or one of the 
orloinal tables, and will therefore be of that identifiable 
type. The aoDlicatlon will be able to successfully use the 
resulting table. 

Meaningless Result - The result of the operation 
will be a table with an identified set of attributes and in 
all probability, at least one tuple. The result will have 
the same structure as the original table, or one of the 
original tables, and therefore win be of that identifiable 
type. However, due to modeling or inefficiency, the 
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resulting table will create difficulties for the 
application. 

Syntactically Incorrect - The operation violates one or 
more of the bounds stated in the definitions presented in 
Section (A) above. 

In the next two subsections the effects of the various 
ooerations win he discussed. Subsection (1) will cover the 
results when the operators are used on taoies of. the sa^ie 
type. Subsection (7) will cover operators used on tables of 
differing types, 

I , Intra«Tyoe Operations 

This section win cover the effects of twelve basic 
relational operations when the operands are the sane tyoe of 
tables - text, database, soread-sheet , forn, or rati. This 
section does not cover the results of mixed tyoe operations 
as they will be covered in Subsection (2), At the conclusion 
of this Subsection, Table 4,1 will summarize the findings. 
The very simple operations such as INSERT, MODIFY, and 
DELETE will not be discussed in the context of each table 
type since they are the minimum ooerations necessary to 
manipulate data in any table type and therefore meaningful 
for all table types, 

a. Text Table Tyoe Operations 

The incompatibility between a text file and its 
representation as distinct units are revealed when 
attempting to apply the relational operators to the text 
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table. What Is in a tuple of text is merely a substring from 
the original text stream. As such, the situations where a 
tuDle can stand alone as data for operations other than text 
processing are limited. Since the domain of the "contents" 
field is all character strings from the character set, there 
is no canonical ordering between the character strings. 
Whereas eouallty between contents fields can be established, 
there is no other coToarlson operator which win have 
aDplicablllty, 

( 1 ) Prolectien 

The PROJECTION operation is meaningful, 
since it is necessary to retrieve either the "contents" or 
the "id" field from the text table. 

( 2 ) Selection 

The SELECTION operation is meaningful but 
there are restrictions. Tuples would be selected from the 
table by nerforming the SELECTION condition on the "Id" 
field. The "contents" field oresents difficulties when used 
as a basis of the SELECTION condition since it can only be 
compared for equality, and that requires an exact 
specification of the contents in the condition. 

(3) Union 

The UNION operation is meaningful on text 
files and results in "apoendlng" the second file to the end 
of the first, but there are modeling problems. The 
resulting text table could have more that one tuple with the 
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same "id" field. For this reason the UNION operation should 



be considered with care, 

(4) Set Difference 

The SET DIFFERENCE Operation is meaningful, 
but there are modeling oroblems. This ooeration must be 
used Keeping in mind its exactness. Only tuples from the 
first table exactly match! no tuples in the second win be 
removed. It cannot be ouaranteed to remove duplicate 
strings from the text file since the text table model cannot 
accurately represent the text file, 

(5) Cartesian Product 

The C4PTESTAN PRODUCT is incorrect since 
the resulting table structure will have duollcate 
attributes. 



( 6 ) Intersection 

The INTERSECTION operation is meaningful, 
but there are modeling problems. The result would be the 
removal of all tuoles from the first text table that were 
not also in the second text table, it cannot be guaranteed 
to find the common strlng(s) in two text files since the 
text table model cannot accuratelv represent the text file. 

(7 ) Quotient 



The QUOTIENT operation is incorrect since 
both text tables are of the same arlty. 
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C9) Join 



The JOIN operation is incorrect since the 
resulting table would have a structure with duplicate 
attributes . 

C9) Natural Join 

The NATURAL JOIN operation is rneanlngful, 
but since it duplicates the effect of the INTERSECTION 
operation in a less efficient manner it should be considered 
meaningless , 

b, Soread-Sheet Table Type Operations 

( 1 ) Projection 

The PROJECTION operation is meaningful for 
such operations as retrieving the information contained in a 
specific column, or columns, of the table, 

(2) selection 

The SELECTION operation is meanlnoful for 
removing a tuole, or tuples, from the table for processing, 

(3) Union 

The result of the UNION operation on 
spread-sheet tables is meaningful, but there are modeling 
problems. The resulting table could now have more than one 
tuple attempting to represent the same entry position, 
tuples no longer representing the proper entry position, 
and/or entry positions no longer relating to their prooer 
preceding entry positions. It Is almost certain that such 
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problems will occur and for that reason the UNION operator 
should be considered with care, 

(4) Set Difference 

The SET DIFFERENCE operation is meaningful, 
but there are modeling oroblems. The result of the 
operation is basicly those entry Positions that are uniaue 
to the first spread sheet and net to the second. To ensure 
usability the implementation must Include oositional and 
value information in the tuole. The tucle cannot depend on 
order in the table for position, or functions relating to 
other tuples for value, since these other tuoles may have 
been removed by the SFT difference, operation, 

( R ) Cartesian Product 

The CiiPTESiAM PRaOUCT ©Deration is 
incorrect since the resulting table structure would have 
duplicate attributes, 

( ft ) Intersection 

The INTERSECTION operation on spread-sheet 
tables is meaningful, but there are modellno problems. The 
reasons are the same as those given for SET DIFFERENCE 
above , 

(7) Quotient 

The QUOTIENT operation is Incorrect since 
both spread-sheet tables are of the same arlty, 

(8) Join 

The join operation is Incorrect since the 
resulting table structure would have duplicate attributes. 
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(9) Natural Join 



The NATURAL JOIN operation Is meaninqf ul , 
but duplicates the effect of the INTERSECTION operation in a 
less efficient manner and should therefore be considered 
meaningless , 

c. Form Table Type Ooerations 
C 1 ) Projection 

The PROJECTION operation is meaninoful, 
since it can be used for retrieving parts of the bloc*c 
description used in the application. 

( 2 ) Selection 

The SELECTION operation is meaningful, 
since it can be used for retrieving the block descriptions 
used by the application, 

C3) Union 

The UNION operation is meaningful, but 
there are modeling oroblems. The resulting table could 
contain tuples that are competing for the sane position on 
the display. For this reason the UNION operation should be 
considered with care, 

(4) Set Difference 

The SET DIFFERENCE is meaningful, but there 
could be modeling problems. It would be used in finding 
those blocks on a form that are not in common with those on 
another form. Modeling constraints reoulre that the block's 
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location Information be stored in the tuple and not depend 



on order in the table, 

C5) Cartesian Product 

The CARTESIAN PRODUCT operation is 
Incorrect since the resultino table structure would contain 
duplicate attributes, 

( 6 ) Intersection 

The INTERSECTION ooeration is meanlnqful/ 
but there could be modellnq problems. It would be used in 
finding those blocks on a form that are common with those of 
another form, ‘Modeling constraints reoulre that the block's 
location information be stored in the tuple and not depend 
on order in the table, 

C 7 ) Quotient 

The QUOTIENT oceration is incorrect since 
both form tables will nave the same arity, 

C8) Join 

The JOIN operation is incorrect since the 
resulting table structure will have duplicate attributes. 

(9) Matural Join 

The NATURAL JOIN operation is meaningful, 
but duplicates the effect of the INTERSECTION operation in a 
less efficient manner and should therefore be considered 
meaningless , 
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d. Mail Table Type Operations 
Cl) Projection 

The PROJECTION operation Is meaningful in 
retrieving the contents of message fields for use in the 
application, 

(2) Selection 

The SELECTION operation is meaningful in 
retrieving a message for use in tne apolicatlon, 

C3) iTnlon 

The UNION operation is meaningful in adding 
new messages to the message table by appending mailboxes 
together, but there are modeling problems. The resulting 
mailbox could have more than one message with the same "id" 
field. For this reason the union operation should be 
considered with care. 

C4) Set Difference 

The SET DIFFERENCE operation is meaningful 
in finding those messages in one mailbox that are not in 
another , 

C5) Cartesian Prodiict 

The CARTESIAN PRODUCT operation Is 
incorrect since the resulting table structure win have 
duplicate attributes, 

C6) Intersectibn 

The INTERSECTION operation Is meaningful in 
finding those messages that are common to two mailboxes. 
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(7) Quotient 



The QUOTIENT operation Is Incorrect since 
both mall tables are of the same arlty. 

(8) Join 

The JOIN operation Is Incorrect since the 
resultlnq table structure >flll have duplicate attributes, 

(9) Natural Join 

The NATUPIL JOIN operation Is meanlnoful, 
but produces the same effect as the INTEOSECTION ©Deration 
'.tflth less efficiency, therefore It should be considered 
meaninqless , 

This section has described the ooeratlonal effects 
of the basic operations when used on one or two tables of 
the same tyoe. Flnure 4,1, on the next oaoe, summarizes the 
findlnqs of this Subsection, 

2 , Inter-Tvpe Operations 

The previous section covered the effects of the five 
binary ooerators when conducted on tables of the same type. 
This section will cover these operators when used only on 
tables of differing types. Table 4,2 will summarize the 
findings of this Subsection, 
a. Union 

Since the UNION operation can only produce a 
usable output table when the structure of the two tables are 
identical, this binary ooerator could only be meaningful 
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when one of the tables was a database type that happened to 
match the structure of the other table. In this special case 
the result would be meanlnqful, and In all other cases the 
UNION operation is Incorrect. 



Table 4,1 - Intra-Tyce Operations, 
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M = Operation is meaninoful. 

CW] = Operation is Tieaninaful. but there 
are modelina nroblems, 

- = Ooeratlon Is incorrect, 

* = Ooeration meanlnoless due to duplication. 



b. Set Difference 

Since the SST DIFFERENCE ooerator can only 
produce a usable output table when the structure of the two 
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tables are Identical, this binary operation could only be 
meaningful when one of the tables was a database tyoe that 
hapoened to match the structure of the other table. In this 
sbeclai case the result would be meaningful, and in all 
other cases the SET DIFFERENCE operation is incorrect. 

c. Cartesian Product 

The CARTESIAN PRODUCT operator can oroduce a 
meaningful table structure for all combinations of table 
types that will not result In a table with duplicate 
attributes. The oresence of duplicate attributes in the 
resulting table would malce the CARTESIAN PRODUCT ooeratlon 
incorrect . 

d. Intersection 

Since the INTERSECTION operator can only produce 
a valid output table when the structure of the two tables 
are identical, the operation would only be useful when one 
of the tables was a database tyoe that haopened to match the 
structure of the other. In this special case the result 
would be meanlnaful, and In all other cases the INTERSECTION 
ooeratlon is Incorrect, 

e. Ouotient 

The QUOTIENT operator can only produce a 
meaningful outout table when the arity of the second table 
is smaller than the first, and all its attributes are also 
found in the first table. This would then limit the tyoe of 
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the second table to database, and then require the proper 
table structure for the quotient operation, 
f. Join 

Given the fact that the actual structure of each 
table type is an implennentation issue and therefore 
variable, it is conceivable that all table types could have 
at least one column structure in common vith another table 
type and the JOIN operation would produce a meanlnaful 
table. 

q. Natural Join 

For the same reasons as stated for the JOIN 
operation, it is conceivable the the NATURAL JOIN operation 
would produce a valid and potentially useful table. 



Table 4,2 - Inter Tyoe Table Ooerations 
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Table 4,2 - (cent.) 
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M = Operation is potentially meanlnoful, 

? s Operation could produce a meaninqful 
result but depends on the database 
table structure, 

- = Operation is incorrect, 

= Intersection of same command, effects 
covered in section 4,B,l and Table 4,1, 
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V, APPLICATION LEVEL INTERFACE 



In the preceding chapters the structure of the 
conceptual level of the IASS has been covered. Chapter 3 
discussed the table as a comnon data object, and Chapter 4 
introduced the primitive ooerations allowed on the table. 
This chapter win describe how each of the aoolicatlon level 
packages Interfaces to the conceptual level. All application 
oackaces in the IASS must maXe use of the comnon data object 
as an important part of their modeling effort. If the common 
data Object can closely model a given application, then 
maximum use can be made of the conceptual level In order to 
accomollsn tne aoplicat ion's functions. However, if the 
common data object is a ooor model of the acollcatlon, then 
the aoplicat ion will have to provide more of Its own service 
needs and therefore will create a large anolicatlon specific 
series of operations. 

In Chapter 4 the twelve basic primitive operations of 
the conceptual level were discussed, and they are listed 
acaln in Table 5,1, These operations will be discussed as 
system level operations where thev are invisible to the IASS 
user. Those lASS operations that are visible to the user 
will be discussed in Chaoter 6, 

In Chapter 2 the basic user visible functions of each 
application were grouped into six command cateoories; 
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<Create>, <Insert>, <Modify>, <Deiete>, <Move>, and 
<Retrleve>, When Issued by the user they will cause the 
abDilcatlon to oerforn one or more operations In support of 
the user. while the use of the conceptual level by the 
application is oenerally invisible to the user, the sample 
list of Included operations can be viewed as to how they 
will support the six visible command categories. 



Table 5,1 - Conceptual Level Primitive Operations, 
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In the following sections each of the five included 
application packages will be covered as to use of the 
Conceptual Level and tneir own "Workspace", What is meant 
by the aopllcatlon's "Workspace" is that oart of the 
application program where the operationally specific 
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functions of the aoDllcatlon occur. This would Include 
variables, constants, proaram logic, buffers, and whatever 
other implementation specific items are necessary. The 
Worksoace Is what makes each application unique to the user 
and is the part that must be Inserted when a new aopilcatlon 
is added to the IASS. It is not the Intention of this 
chapter to focus on the worksoace, so Its coverage will be 
general and b’*lef. The primary oolnt of interest will be how 
each aopilcatlon can mai^e use of the conceotual level. 

In discussing use of the conceptual level, application 
soeclflc operations will be described where each requires 
the use of one, or more, conceptual level oneratlons. If 
one apnllcatlon ooeration can be defined in terms of a 
previously defined aopilcatlon operation, the previous 
ooeration will appear in brackets, 

A. EDITOP/WORD PROCESSOR 

As discussed In Chanter 3, Section (A), the Edltor/word 
Processor (E/WP) oresents the greatest modeling oroblem for 
the conceptual level. This means that the E/wp will oerform 
the majority of its ooeration In the workspace and not at 
the conceptual level, 

1 . E/wp Workspace Operations 

A lane number of the operations necessary to model 
the E/WP will have to be located In the Workspace area since 
the data-table Is a boor model of text. Some of the 
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operations necessary at the Wo r!< space level are; 
reassembling text tuples into a continuous text stream. 
Keeping tracK of the proper orderina of text tuples, 
oerforming string searches, blocK moves, and character 
replacements. All operations for formatting and display 
will be conducted here, 

2 . E/wp Conceptual Level Operations 

Althougb there are modeling problems with text, it 
does not mean that the E/WP cannot make use of the 
conceptual level. The following operations use the 
conceptual level but do very little direct manipulation of 
the text, since that is performed in the workspace. The 
operations themselves were chosen based on a perceived 
mlntmun application need and the ability to use the 
conceptual level. This is not a complete listing of 

possible E/wp operations since tnat is a very implementation 
dependent question, 

a. Insert Text Tuple 

As the Workspace finishes with enough characters 
to constitute the "contents" field of a tuole, it will 
determine the prooer "Id" field seguence for the new tuple 
and then issue an INSERT operation to olace the tuple in the 
table, 

b. Get Text Tuple 

The E/WP must determine the "id" of the next 
tuple it needs, A SELECTION is performed, based on that "id" 
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field. The resulting tuple Is then DELETE'ed from the 
original table and the "contents" field of the result is 
PPOJECT'ed out and placed in the Workspace, 

c. Append Text Files 

The Workspace will <Get> the last tuple from 
flie-1 and then oroceed to SELECT each tuple from flle-2. In 
ordar. PPOJECT'ing out the "contents" field, and place it in 
the worksoace. As the Worksoace gets enough characters to 
make a comolete tuple, it will <Insert> the tuple Into the 
end of file-1, 

d. Insert A Text File 

The Workspace will <Get> tuples from table-1 
until it finds the correct insertion oolnt. Then all tuples 
will be SELECT'ed fro»m table-2, nne at a time, in "id" 
order. The "contents" field of each will be PPOJECT'ed out 
and placed in the workspace. As the Worksoace gets enough 
characters to form a comolete tuole they will be <Inserted> 
Into table-l with the orooer "id" field. When all tuoles 
from table-2 have been copied into table-1, the worksoace 
will <Get> the remaining original tuples from table-1 and 
<Insert> them back into table-1, 

e. Delete To A Buffer 

The Workspace will <Get> tuples from the 
referenced table and <Insert> them back into the table until 
it finds the oolnt at which the deletion Is to beoln. From 
that oolnt it will continue to <Get> tuples from the table 
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until it finds the point at which the deletion is to stop. 
As the Workspace collects enough characters to form a tuple, 
it will assign a ore per "id" and INSERT the tuple in the 
buffer table. After the stop ooint, the Workspace will 
continue to <Get> tuples from the referenced table, and will 
<Insert> completed tuples back into it until the end is 
reached, 

f. Copy To A Buffer 

The Works oace will <Get> tuples from the 
referenced table and <Insert> them back into the table until 
it finds the ooint at which the cepyino is to beoin. From 
that ooint it will continue to <Get> tuples from the table 
until it finds the point at which the cooying is to stop. 
As the workspace collects enouoh characters to form a tuole 
it will <Insert> them, with their original "id", back into 
the table. Simultaneously it win imsfrt the same tuples, 
with new "id” fields, into the buffer table. After the stop 
point, the Workspace win continue to <Get> tuples from the 
referenced table, and will <Insert> comoleted tables back 
into it until the end is reached. 

The use of the conceotual level by the E/wp is 
summarized in Table 5,2. 

B. DATABASE MANAGEMENT SYSTEM 
I , Database Workspace 

Since the DBMS packaae is a relational database 
system, the user win be permitted direct access to the 
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conceptual level primitive operations without constraint. 
The user accents complete responsibility for the validity 
and usefulness of all actions. This means there is little 
need for a Workspace since the user does just about 
everythlnp. 



Table 5,2 • Editor/Word Processor Interface, 
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X = Primitive operation is used, 

- s Primitive oeeratlon is not used. 



2 • Database/Conceotua 1 Level Operations 

As stated above, the user is permitted direct access 
to all the conceptual level orlmitive operators. There are 
no limits olaced on the user in structurlno these ooerators 
to produce a desired result. However, it is obvious that in 
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implementation some issues will be encountered that will 
place limits on the user, 

C, SPREAD-SHEET 

The soread-sheet is very similar to a database in that 
it stores the facts related to a user defined "real-world" 
situation, l.e. it is a model. The maior difference is that 
the user is limited to the predefined retrievals and 
displays Provided by the spread-sheet. The spread-sheet has 
control and resoonsibillty for the operation, 'j»hile the user 
has responsibility for the content, 

1 . soread-Sheet workspace Operations 

The wcrXsoace is responsible for use of the spread- 
sheet data table since the user does not see or manipulate 
it directly, it contains the loqic necessary to interface 
with the user and control the display. 

2 , Soread-Sheet Conceptual Level Operations 

As the user Issues application specific commands the 
Workspace translates them into a series of application and 
conceptual level operations. The list of Included 
operations cannot be claimed to be definite or complete 
because that is an implementation issue and really without 
bounds. However, the list is considered to be a workable set 
of operations for a representative spread-sheet application. 



70 




1 



I 





ife 



a. Update Entry Positions 

The wor'cspace must icnow in which order entry 
positions are to be updated, "row" or "column" order. Each 
entry position Is SELECT'ed In turn based on Its "location" 
field, and its "function" field is PROJECT'ed out. The 
Worvjspaee evaluates the contents of the "function" field, 
and resolves references to other entry nositlons by 
SELECT'lno them and PRCJECT'ino out the "value" field. When 
the new value Is finally computed, a MODIFY operation Is 
conducted to chanoe the "value" field. The Worvcspace 
continues until all entry positions are updated, 

b. Maxe An Entry In A Entry Position 

The Workspace must know -vhich column and row 
entry position is betna referenced, and the value or 
function to be entered, A ’MODIFY operator win be used, 
based on a condition statement, to find the tuole with the 
proper "location" entry and then chanoe Its "function" and 
"value" field. If the Soread-Sheet is In automatic 
recalculation mode, then related entry positions will have 
to be <Updated>, 

c. Add A New Column Or Row 

The workspace must know the column or row on the 
spread -sheet that Is being referenced and where the new 
columr/row is to be Placed relative to It, The modify 
operator win be used to find those entry positions that 
must be moved, and chanoe their "location" and "function" 
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fields to take Into account the shift In position. New 
tuples, with "location" fields corresponding to the added 
row/column win be INSERTED, Lastly, all entry positions 
will be <Uodated>, 

d. Delete A Column Or Row 

The worksoace must know tne column or row on the 
spread-sheet that Is being referenced. A DELETION ooerator 
is Issued •vltb a condition statement corresoondinc to the 
proper "location". Next, a MODIFY operation Is conducted on 
the "location" field of the orooer entry positions necessary 
to close the resulting gap, Lastlv, all entry positions will 
be <UPdated>, 

e. Append Soread-Sheets 

Th* Viorkspace Tiust know whether sheet-2 is to be 
appended to the side or bottom of sneet-l. Given that 
Information, a SELECTION is done on sheet-1 to find the 
maximum "location" field and it Is PROJECT'ed out and saved 
In the Workspace, A MODIFY operation is next conducted on 
all tuples In sheet-2 to add the proper, row or column, 
value saved above to all entry Position references in the 
"location" and "function" fields of sheet-2. Sheet-2 Is 
then UNION'ed to sheet-1, and the resulting sheet Is 
<Updated>, 

f. Spread-Sheet Intersection 

Given that you want to display the common entry 
positions of sheet-1 and sheet-2: Perform the INTERSECTION 
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operation between sheet-1 and sheet-2 



Then 



<Update> the 



resulting table. 

g. Spread Sheet SET DIFFERENCE 

Given that you want to dlsply those entry 
positions that are unique to sheet-1 and not found in 
sheet-2s Perform the SET DIFFERENCE between sheet-1 and 
sheet-2. Then <Update> the resulting table. 

Table 5.1 - Spread-Sheet Interface. 
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X s Primitive operation is used, 

- = Primitive operation is not used. 



The use of the conceptual level by the Spread-Sheet 
application is summarized In Table 5.3, 
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D. FORM GENERATOR 



It Is t.’^e purpose of the Form Generator to create a 
table that will be used at a later time in support of other 
application packaoes or the user directly. The Form table 
is probably the most comolex table of the five Included in 
the IASS 'since it will be called on to do so much. The table 
reads like a set of step by step instructions on how to 
input or output the provided data. As this is a heavily 
implementation dependent application, not much emohasis win 
be Placed on specific uses, 

1 , Form Generator Workspace Operations 

The Workspace in the Form Generator must be fairly 
Intellloent since it has two modes of ooeratlon. The first 
Is "deslan-time*' when it must interpret the user commands 
into a series of block entries In the form table. The second 
is "use-time'* when it must use the information In the table 
to create the desired output form. This reoulres that the 
aepiicatioh loqlc, its ability to interface to the other 
applications, and any needed structures be contained in the 
Workspace , 

2 , Form Generator Conceptual Level Operations 

The Form Generator does little more than build the 
table at "design" time, and read the Instructions in the 
table at "use" time. It therefore seems that it can make 
fairly extensive use of the conceptual level operators. 
However, a complete list of all possible operations is 
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impossible since the Form Generator application seems to be 
the most implementation dependent application of all. The 
list of operations that follows is Intended as a 
representative grouo of basic operations and is not 
definitive. 

a. Clear workspace 

If the Workspace is empty/ then do nothing. 
However, if there are entries In the worksoace then issue a 
MODIFY operation, based on ''location'*, to change those 
fields that have entries. If, no block was found, then issue 
an INSEPT operation to olace the block in the table. 
Lastly, erase the workarea, 

b. Find Block 

First, <Clear> the workspace. Use a SELECTION 
operation to find the new block being referenced, PROJECT 
out the "location" field, and any other fields that are 
needed. If no block was found, then wait for next user 
command , 

c. Add A New Block 

The Worksoace must start blank since it cannot 
have found a referenced block where a new block is being 
added. The user enters the proper information into the 
Workspace and when the user is finished, the Workspace will 
be <Cleared>, 
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d. Edit A BlocX 



When the user edits an already existing block 
then it will have been found by the "Find Referenced Block" 
operation described above. The Workspace will wait until the 
user is finished editing, and then <Ciear> the workspace, 

e. Delete A Block 

<Clear> the workspace. Issue a DELETE operation 
based on the user Generated condition. 

f. Append Forms Together 

<Clear> the Workspace. Given that form-2 is to 
be appended to the bottom of form-1 : Use the SELECT 

operation to find the block with the highest row number and 
lowest column number in form-1, PROJECT out, and save in 
the Workspace, the "row" field. Issue a MODIFY operation on 
all blocks in form-2, and add the saved "row" number from 
form-1 to the "row" field In form-2. Then UNION form-2 to 
form-1 . 

g. Add A Blank Line To The Form 

The worksoace must know the referenced row 
number on the form. Clear the workspace. Issue a MODIFY 
operation on all blocks, on or below the referenced row, to 
uodate their "location" field, 

h. Form Intersection 

Given that the desired display is those blocks 
that are found both in £orm-i and form-2, first <Clear> the 
Workspace . 
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If position on the form is important: Perform 

the INTERSECTION operation on form-l and form-2. Pass the 
resulting table to the Workspace, 

If position on the form is not Important: 
PROJECT out the "promot", ”i/o", and "function" fields of 
form-1 and form-2, Do an INTERSECTION operation on the new 
tables and then natural JOIN the result to the orlainal 
table-1, Pass the resulting table to the worksoace, 
i. Form Set Difference 

Given that the desired disoiay is those blocks 
in form-1 that are not found Ir form-2, first <Clear> the 
workspace. 

If Dosltlon on the form is important: Perform 

the SET DIFFERENCE between form-1 and form-2, Pass the 
resulting table to the workscace. 

If position on the form Is not important: 
PROJECT out the "promot", "l/o", and "function" fields of 
form-1 and form-2, Perform the SET DIFFERENCE between these 
resulting tables. Take this result and NATURAL JOIN it to 
the original table-1, Pass the resulting table to the 
Workspace, 

The use of the conceptual level by the Form 
Generator application is summarized in Table 5.4, 
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Table 5,4 - Form Generator Interface 
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X s Primitive operation Is used. 

- s Primitive operation Is not used. 



E, ELECTRONIC MAIL 

The purpose of the Mall application Is to enable the 
user to leave messages for other users who are not presently 
available. Again this Is a very Imoiementat Ion dependent 
application In determining exactly what services you wish to 
provide. As before, Implementation Issues will be avoided as 
much as possible. 
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1 , Electronic Mall Worl<space Operations 



The Woricsoace Is responsible for translating user 
commands Into application ooeratlons necessary to create and 
read messages. It contains the logic necessary to use the 
Mall table, Interoret user commands, and control the 
display , 

2 . Electronic Mall Conceptual Level Operations 

A fairly wide range of aoDilcation ooeratlons can be 
accomplished by using the conceptual level ooeratlons. 
While the following list of operations cannot be considered 
complete or definite, it is reoresentative of an Electronic 
Mail aoollcatlon, 

a, Plc'cuD Mall 

Unon entering the IASS, the MAIL system is 
automatically directed to pickuo any mail for the user. The 
MAIL system generates a SELECTION ooeratlon on the system 
mailbox with the condition that the message(s) is addressed 
to the user. The resulting table is SET OIFFERENC'ed with 
the system mailbox and then UNlON'ed with the user's 
mailbox. 

b * Read M3 1 1 

The workspace must have an "id" of the desired 
message, A SELECTION operation Is performed on the user's 
mailbox based on the "Id" field. The subparts of the 
message are PROJECT'ed out and oiaced In the workspace. 
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c. Find Mall 

Given a user entered condition statement the 
Wortcarea will generate a SELECTION operation based on that 
condition. The proper fleld(s) of the messages will be 
PROJECT'ed out and placed In the Worksoace to support an 
aporoorlate display, 

d. Edit A Message 

The Workspace will know the "Id" of the message 
being edited. When the user is completed, a MODIFY operation 
will be Issued based on that "Id" to change any fields that 
were edited. If no message with that "Id" was found by the 
MODIFY operation then It must be a newly created message and 
the Workspace will INSERT It Into the user mailbox. 

e. Delete Mall 

The worksnace will know the "id" of the 
messageCs) or be given a user defined condition statement. 
Based on these, a DELETION operation will be performed on 
the user's mailbox, 

f. Multi-hat 

Given that the workspace has a single message 
with a multi-hat destination; PROJECT out the contents of 
the "to" field in the message, and olace It In the 
Workspace, The workspace win find a database "alias" table 
with that name which has "id" and "to" fields. The tuples in 
this table correspond to the actual names In the multi-hat 
name. Taking the original message, PROJECT out the "from", 
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"subj", "cJate", and "body" fields, TaKe the result and 
perform a CARTESIAN PRODUCT with the alias table. Now UNION 
t>^e results with the system mailbox, 
o. Send Mall 

Each time the user leaves the Mail application, 
any outgoing mall is automatically sent. The Workspace 
generates a SELECTION based on the condition to find all 
messaces not addressed to the user. The resulting "outgoing'’ 
table Is SET OIEFERENC'ed with the user's mailbox, A 
SELECTION is then performed on the outgoing table to find 
any multi-hat destinations. The resulting multi-hat table is 
SET DIFFERENC'ed with the outgoing table, and the remaining 
outgoing messages are UNION 'ed with the system mailbox. The 
.messages in the multi-hat table are then SELSCT'ed one at a 
time, DELET'ed from the multi-hat table, and then processed 
by the <Multl-Hat> operation, 
h. Mall Synoosls 

poOJECT out the "from", "to", and "subject" 
fields of all the messages in the user's mailbox. The 
Workarea will use this new table by SELECT'lng each message 
in "id" order, PROJECT'lng out the three fields, and using 
the results to create the display. 

The use of the conceptual level by tbe Mail 
application is summarized in Table 5.5, 
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Table, 5, 5 - Mall Intersection 
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X = Primitive operation is used, 

- = primitive ooeration is not used. 



The results of the precedlnq five sections are 
summarized in Table 5,6, It shows that the application 
pacicaqes can make extensive use of the majority of the 
primitive operations found at the conceptual level. This 
chapter has not tried to show all the possible application 
operations and their use of the conceptual level. Instead a 
fairly representative and basic set of operations was 
discussed. The actual list of operations included in each 
IASS application will be a very implementation dependent 
issue. 
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Table 5,6 - Application Intersection Overview 
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X = Primitive ooeratlon is used, 

- s Primitive ooeratlon is not used. 
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VI 



USER INTERFACE 



The Integrated Application Soft>^are System (IASS) 
combines the capabilities of the five software application 
packages described in Chaoter 2, Each of these aoDllcations 
performs a set of functions on an associated logical file 
type. Tnteoraclon of these distinct systems is orouont 
about by determlnino the set of common functions performed 
by each system on the associated logical fils type, defining 
a common data object to represent the logical file types, 
and finally deflnlno a system of primitive operations on the 
common data object. 

The previous chapters have covered the integration 
aporoach. at the system level, where it is Invisible to the 
user. Another integration level is vital to the IASS design 
and it must occur where the user interfaces to the lASS's 
anpllcat ions . The result of integration at the user 
interface will be a system-wide, common set of user 
operations and associated commands, and a regular display 
organization of the logically distinct file tyoes at the 
user interface. This is probably the most important command 
Interface since it is the one the user can actually perceive 
and evaluate. 

Implementation of the IASS reouires designing for one 
conceptual display model using a single physical 
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Figure 6.1 - TASS Hierarchy 
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A, USER INTERFACE MODULE 



The Interface between the user and the system couples 
the user to the applications of the IASS, and allows control 
of the operation of the system. The User Interface Module 
(HIM) Is an abstraction to contain the features of the IASS 
which the user can assume are present In any context of 
system use. The UIM encompasses both the environmental and 
operational assumptions of the system. 

The UIM Is not a stand-alone <»ntlty. It depends heavllv 
on each application orooram to Interpret the user Input, and 
to determine the appropriate display structure. It is the 
application proqram that translates the common UIM commands 
Into a series of application operations that may, or may 
not, make use of the conceptual level, 

1 . UIM oisplay Format 

The point of observation of the system is the 
terminal screen, which, is a finitely dimensioned "window" 
into the logical file or data oblect in reference. For all 
applications the display size is not limited to the size of 
the screen window. If the display is large, the user will be 
able to use the UIM to maneuver the window over the disc lay 
to accomollsh the desired tasks. The UIM does not control 
the type of dlsolay presented to the user, since this ts an 
application dependent reoulrement. However, the UIM does 
give the user a consistent method of Interacting with the 
display as the apollcations change. 
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2 . UIM Cemmand Line 



Th« UIM uses a common disolay organization which is 
augmented by the specific application orogram in use. In any 
context of use, the top line of the screen is dedicated for 
presentation of the UlM command line. The next line will 
always be used by the application program for its command 
line. In this manner, the top two lines of the screen will 
always contain system information and oromnts for the user, 
3, UIM Editing 

From the results of the reguirements analysis phase 
of this study, the function which is common to each utility 
Is that of making chanoes to a referenced file, i.e, 
editing. All the really provides the user with is 

screen edltlna features. It will be the apollcation srogram 
that Interprets the commands into more comolex 

operations. Editing should he done on-screer, witn 

Immediate feedback available to the user. For user 
protection, all editing will be done on a copy of the 
designated file and only committed as a permanent 
modification when explicitly directed by the user. The 
common set of editing commands provided bv the UIM may oe 
augmented by functions from the underlying application 
proaram to ensure that special editing actions, which are 
specifically associated with a logical file type, are 
executable. 
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4. UIM Comniands 



The operational assumptions of the IASS UIM 
compromised a set of user commands. These commands can be 
assumed to produce a similar effect when executed in any 
context of system use. It is the ourpose of each application 
to provide the appropriate translation between the Uiv 
commands, the dlsday of the data object, and its conceptual 
representation , 

Based on the cateoories of commands defined in 
Chapter 7 , there are three major catecorles of commands in 
the UIM, The first is "Movement" commands that control the 
oosltlon of the cursor on the screen, and the location of 
the screen in reference to the aoolication disolay. the 
second category, is "Editing" commands tnat make additions, 
deletions, and/or changes to the data in the disolay. The 
third category is "System" commands tnat are not used by the 
application, but by the IASS to oerform its "housekeeping" 
functions. There are many different methods for attemotlng 
to oresent these categories to the user, and they are all 
implementation dependent. For the purpose of this thesis a 
possible listing of standard UIM commands is given in Table 
6 . 1 . 

All Of the basic cateoories presented In Chapter 2, 
with the exception of the <Modify> command, are directly 
Implemented bv UIM commands. There did net seem to be any 
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sliDDle way, short of accepting a complex command syntax, to 
Implement one UTM command oer category. 



Table 6,1 - UTM Commands 



UIM 

CATEGORY 




UTM 

COMMAND 


CHAPTER 2 
CATEGORY 


Movement 


1. 


Move cursor 
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Enter Application 


Create 
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Output 
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11. 


Save Changes 


- 




12, 


Quit Application 


• 



The <Modl£y> category did not need a command of its own 
because it became apparent that the apnllcatlon Itself will 
be able to determine when modification is necessary based on 
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use of the UIM, In Section CB) which follows, each of the 
five applications will be covered with the Intention of 
showlnq how they use the standard UIM commands to imolement 
the command cateqorles of Chapter 2, 

3, APPLICATION PPOGRAM LEVEL 

The Aoolicatlon Proaram Level (APL) consists of the 
actual aoolicatlon procrams that interface to the user 
throuoh the UTM, and operate on the common data object by 
the orlmitlve operations available at the conceptual level. 
Each application oroqram has a specific user support 
function and althouqh it uses the common UIM It has certain 
features that make it unioue. Each of tha IASS apolicatlcn 
proorams win be discussed In the followin'? sections. 

p’our areas of each aoolicatlon will be discussed. 
First, the display format used by each aocllcatlon to take 
advantace of the features of the UIM, Since the screen will 
be the common inout/outnut medium for the IASS It is 
important that the perceived use of the display be similar 
between apoilcatlons , Second, the editlnc features of the 
application, Aoaln, as this Is part of the common interface 
medium for the IASS it is important that the user perceive a 
similarity between edltina features in each application. 
Third, specialized "functions" of the aoolicatlon. These 
are the unicue features of each application that will 
differentiate them from other Included applications. 
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Fourth, use of the standard UIM commands by the application. 
This will show how the application will use a standardized 
command to perform an application specific operation, 

1 , I&SS Fdltor/Word Processor 

The lass text table Is not limited by deslqn to 
support 1 no any one type of editor and word processor 
arranoenent , However, as was pointed out previously, the 
on-screen editor with on-line formattino is rapidly becomlno 
the acceoted standard and any reqression to line oriented 
editors, or the like, would meet with serious user 
resistance. For this reason an on-screen editor with on- 
line formatter is assumed, 

a, S/wp Dlsolav Format 

The Editor/ Word Processor (S/wp) has a sinqle 
display called "nace" format, and Flqure 6,2 orovldes an 
illustration. The screen reoresents a window over the sheet 
of caper on which the text Is belnq written, what the user 
sees throuqh the window is tne format that will actually be 
output, Thn default Word Processor (WP) settlnos win match 
the size of the E/WP display to the size of the screen Cl.e, 
no part of the text win be hidden off either side of the 
screen). However, the user Is free to Issue wp commands that 
win result in a display larqer than the screen. In this 
case the user will have to use cursor movement commands to 
bring the off-screen portions into view. 
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{user entered coininand} R## C## {Textflle Name) 

...*....2. ..3. .4. ..5. ..6. 

If you're not using the standard library, or if 
will have to construct calls to other programs usi 

m M 

jthrough temporary files. Here it Is natural to maK| 

rioure 6,2 - "?aae" Disolay Format for Sditor/Word 

Processor , 

(Display size is laroer than screen size.) 
b, £/WP Editing 

All text files maKe use of the word Processor 
(Wp), and it is always on-line. At entry the wp is set to 
certain default output values for pace length, line size, 
line spacing, left maroin, right margin, and tab size. The 
user can accept these default settings or can Isstje commands 
to the E/WP to chance them. The E/wp continuously scans the 
text stream, recognizes the commands, and immediately 
chances the output format. 

Editing is accomolished by positioning the 
cursor at any noint on the screen and typing in an entry. 
The entry Is Inserted between the present contents of the 
location. Deletion and modification are accompli sned in a 
similar on-screen manner. Only commands that make use of 
large objects, like blocks or other files, need resort to a 
command-line format. As the E/WP formatter is always on- 
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line. 


the user 


does 


not have to 


worry 


about 


starting 


new 


lines , 


indenting, 


line 


spacing, new 


page. 


and other similar 


format 


considerations , 


The E/WP 


automatically 


do**s it 


for 


the user, but the 


user 


can still 


take 


manual 


control 


if 


reouired. 















To assist the user in certain editing situations 



the E/wp will provide a certain number of buffers for the 
user to treat as temporary storage areas, Actually they are 
temporary text flies created bv the S/wp and are destroyed 
when the session is ended. 

The E/WP actually operates on a copy of the 
orlainal file, so anv chanoes made during a session only 
become permanent when the user Issues a "save" command. If 
the user quits without saving, then it is as if the session 
never occurred, 

c, E/wp Functions 

( 1 ) Formatting Commands 

A series of specialized Word Processing 
commands must be Included in the E/WP application to allow 
the user to modify the format of the text. These commands 
must be structured in such a way so that they are readily 
distinguished in the text stream and will not be mistaken 
for text. 
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d, E/WP Commands 
(1) Find 

Used to locate character or string sized 
objects specified by the user# The located object is 
displayed by scrolling the window to Its location, and the 
user Is notified if another match exists. This operation 
will use a command-line format. 

C?) Insert 

Used to Place any valid object at a point 
referenced by the cursor. The present contents are not 
overwritten, merely pushed aside to matte room for the new 
object. This operation will use an on-screen format. It Is 

possible to insert laroe objects, such as buffers or other 

✓ 

text flies. Into the file being edited, but this will 
r^cuire the use of a command-li-e format. 

C 3) Move 

Used to change the location of line or 
blocX size objects specified by the user. The object Is 
deleted from Its oresent location and then inserted in the 
new location. This operation will require the use of a 
command-line format. 

(4) helete 

Used to remove any object (character, line, 
block) specified by the user. The object Is normally not 
saved, but If the user specifies it can be saved In a 
buffer. This operation will require the use of both on- 
screen and command-line formats. 
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C5) Copy 



Used to duplicate an object and then Insert 
the duplicate at a specified cursor location or into a 
buffer. This operation will reoulre the use of a command- 
line format. 

(6) Add 

Used to create a blanK line(s) on the 
display, above or below the cursor position. This operation 
will reoulre the use of an on-screen format. 

( 7 ) Output 

Used to send the file to some des Iona ted 
output device. The output format of the file will exactly 
match the format seen on the disolav durlnq editlno. 

2 . TA55 Database vanaoement System 

The main Intention of the Data case Manaoement System 
(DBMS) is to etnohaslze simplicity. It does not make sense 
to follow the lead of many currently available DBMS packaoes 
that add larqe amounts of complexity to qain minor and 
seldom used capabilities. 

a, DBMS Displav Format 

There will be two formats In which database 
tables will be displayed. The first, and default format is 
called "table". The table will be displayed In a tabular, 
row and column, format for the user to edit, Floure 6,3 
Illustrates the "table" display format. 
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{user entered command) R## C## {Database name) 

R«t## {Table name) 




Name 


SSN 


Age 


Dept 


Manag 























Flqure 6,3 - "Table" Dlsolav Forfnat for DBMS-Table. 

Tbe second format win be "page", and it 
disDiays the records in a vertical format with no portion of 

e 

the table lyino off-screen to the sides. 



(user entered command) P## {Database Mame) 

{Prompt) F»i» R#t## {Table name) 



Name 

SSN 

Age 

Deot 

Manager 



Comments ; 



Flaure 6,4 - "Page" Dlsolav Format for DBMS-table, 
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Instead, each field has at least one line on which to 
display its contents, and can have more than one line if 
needed. The user will scroll In a vertical direction to 
view the entries in the table, Flqure 6,4 illustrates the 
"paoe" format, 

b. DBMS Edltino 

The DBMS mai<es use of the UIM described in 
section (A), above. However there are some constraints. The 
user is not free to write anywhere on the screen, but is 
limited to writing within field oosltions. Field oositions 
are the bounded locations at column and row intersections 
for the "table" dlsolav, and the locations between the 
delimiters "j" for the "oaoe" disolay. Entries cannot be 
made to nass throuoh field boundaries, and the user wiii be 
oromoted if it is attempted. To cross such boundary 
reouires the use of a cursor motion command. 

The UIM commands will be used to edit the 
dlsDiayed table. Cursor motion Keys will be used to 
position the cursor in a valid field oosltion. Text win be 
Inserted, or deleted, inside the field position. The user 
will be allowed to scroll across the screen in all four 
directions, up to the limit of the size of the table. 

Records are added to the table by editing a 
"bianic" tuple. Blank tuples are found automatically at the 
end of the table display, or created by using the "add" 
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consmand to Insert them above, or below, the present cursor 
position. 

The IASS provides a degree of protection to the 
user in that none of the editing changes (record insertions, 
modifications, or deletions) are made until the user Isses a 
"save" command. At that time the oriolnai table Is removed 
and the copy on which the editing was done takes its olace. 
If the user ouits without savlno, then none of the edltino 
changes are made. 

c, DBMS Functions 

( 1 ) Relational Operators 

The following relational operations 
described in Chapter 4, Section (a) are available to the 
user In the DBMS, The operators are: MODIFICATION, DELETION, 
BROJECTION, SELECTION, UNION, SET DIFFEPENCE, CARTESIAN 
PRODUCT, INTERSECTION, QUOTIENT, JOIN, and NATURAL JOIN. 
The INSERTION operation Is not included since It Is already 
performed by the UIM, and the MODIFICATION and DELETION 
operands are for mass operations where usina the UIm 
modification and deletion capabilities would be too 
difficult. All these operations would require the use of a 
command- line format. The unary operations (MODIFICATION, 
DELETION, PROJECTION, and SELECTION) must be used with a 
DBMS table already in reference. The other binary ocerations 
will have to specify the DBMS tables involved as part of 
their command-line format. 
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(2) Arithmetic 



In suoport of conditional statements and 
query processing the DBMS will have to Include a basic 
arithmetic capability. The following operations are needed: 
Addition, Subtraction, Multiplication, Division , Equals, 
Greater-Than , Less-Than, Greater-Than-Or-Eoual-To , and 
Less'-Than-Or-Equal-To , These are not intended as stand 
alone operations, but are necessary to the successful 
oerformance of other operations, 

( 1 ) Aggregate 

In support of conditional statements and 
query orocesslng the DBMS will have to have a basic 
aogregate function set. The following functions need to be 
Included; Total, Count, vax, Min, and Average. These are 
not intended as stand alone operations, but ar« necessary to 
the successful performance of other operations. 

(4) Query Processing 

In support of user defined ouestlons across 
multiple DBMS tables, there must be a capability similar to 
the "Bind" command, only not limited to a slnole table. The 
result of a guery would be a new table containing the 
desired Information, but no change would have been made to 
the tables that provided the Information. A command-line 
format would be required for this operation. 
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d, DBMS Commands 
(1) Find 

Used to brlnq a tuple, from the single 
table In reference, that meets a specified condition onto 
the screen by scrolling. Additionally, the user is notified 
if another tuple meets the same condition. This ooeration 
will reau Ire the use of a command-line format. 

C2 ) Insert 

New tuples are added to a table by editing 
’’blanK" tuples. Plank tuoles are automatically found at the 
end of the table, or are created by using the "add” command 
to Insert them above, or below, the Present cursor oosition. 
This ooeration Is performed In an on-screen format, 

C 3 ) Delete 

?y using the UT'^ editor features a single 
tuple can be deleted, in an on-screen format. However, for 
multiple tuple deletions a command-line format would be 
required . 

(4) Add 

As an aid to the user, the add command will 
place a "blank" tuole either above or below the tuple 
referenced by the cursor. This operation Is oerformed in an 
on-screen format. If no entries are made in the blank 
tuole, it is Ignored by the DBMS application. 
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(5) Output 



Used to send the contents of a table, or 
tables, to some desionated output device. The output format 
always defaults to the "table" display, Tf more 
sophisticated output formats are desired then a Form 
Generator table can be specified to control the cutout, 

3 , IASS Soread«Sheet 

The soread-sheet application is a fairly well 
defined and concent u ally simple program. Its functions are 
well defined and it is not expected to react to unexpected 
demands , 

a, Spread-Sheet Display Format 

Soread-sheet has a slnole display format and it 
is called "tahle", Fig>:re S.5 illustrates the "taole" 
display, Hniy the value of ^ach entry position is 
displayed, not its functional content. The soread-sheet 
"table" display does not have a direct correspondence to the 
spread-sheet data table described in Chapter 3, Section (C) 
since there is no need for the user to be concerned with how 
the aPDllcatlon orooram must use it. 

b, Sbread-Sheet Fditlno 

The soread-sheet maifes use of the UIM described 
in Section (A), above. However, this application make* use 
of two cursors which are related to each other. The 
"Position" cursor is the lower one, and it moves across the 
columns and rows of the "table" display. Its function is to 
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indicate which entry position is currently belnq referenced 
by the application. 



{user entered command) R## Ct* { soread-sheet name) 
{prompt) C#* 






A 


B 


C 


D 


E 


F 


G 


H 


1 


















2 
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Flaure 6,5 - ’’Table" Dlsplav Foriiat for Soread-Sheet . 



The UTM cursor 'notion commands control the "oosition" cursor 
and allow it to roam over the entire spread sheet. The 
"command" cursor is always in the command line area of the 
screen, and is used to write into the entry oosition mar*<ed 
by the "position" cursor. It is on the command line that 
the functional contents of tne referenced entry position are 
displayed . 

c, Soread-Sheet Functions 
( 1 ) Arithmetic 

Since the Spread-Sheet is a numerical 
modellno tool it will need a substantial arithmetic 
capability. The followinq operations are needed; Addition, 
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Subtraction, Multiplication, Division, Exponentiation, 
Absolute value, Truncation, Roundlno, Logarithms, and 
Trigonometric Functions, These operations must be caoable 
of stand alone operations similar to those in a calculator, 
and be capable of inclusion in other operations and 
conditions , 

( 7 ) Aggregate 

Since the Spread-Sheet is a numerical 
modeling tool it will need a substantial aggregate modeling 
capability. The follo'^lno operations are needed: Total, 

Count, Maximum, Minimum, Average, and Met-Present-Vaiue , 
These operations will not have a stand alone capability 
since they are Intended for inclusion In other ooerations. 
d, Scread-Sheet Commands 
Cn Find 

Used to find those entry oositions. In the 
referenced spread-sheet, that meet some specified condition. 
The cursor win be Placed on the first such entry oosltlon 
and a prompt generated to show if there is another. This 
ooeratlon will reoulre the use of a command -line format, 

(2) Insert 

Used to place the contents of another 
spread-sheet alongside the current spread-sheet at the 
indicated edge. This operation will require the use of a 
command-line format. 
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( 3 ) Move 



Used to chanoe the current position of an 
entire row or column on the spread-sheet. This operation 
will require the use of a command-line format, 

(4) Delete 

In reference to a specific entry position, 
it sets the value to null. For rows or columns It totally 
removes them and moves the surrounoina rows and columns to 
fill the oao. This ooeration win reaulre the use of a 
command-line format, 

(5) Copy 

Used to duplicate a row, column, or 
specific entry Position at another referenced location. This 
operation will reaulre the use of a command- line format. 

(6) add 

Used to Place a blani<: row or column in a 
location referenced by the present cursor position. This 
operation win reaulre the use of a command- line format. 

(7) Output 

Used to send the contents of the soread- 
sheet to some indicated output device. The user can indicate 
whether to send the soread-sheet display, which only 
contains the entry position values, or the contents of the 
actual spread-sheet table, which contains both the value and 
the function, to the output device, Suboarts of the whole 
soread-sheet may be indicated for output. 
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IASS Form Generator 



The Form Generator will be an Important part of the 
IASS since It is reasonable to expect other apolicatlons » 
the DBMS for example, to make use of it to suooort their 
operations. It also has two modes of operation, "Desion" 
time is when the new form is prepared by the user and all of 
its parts, called "blocks", are oositioned and Identified as 
to their function, "Use" time is when the oreviouslv 
designed form is called on to outout the specified 

Information in the prescribed format, 
a. Form Disolav Format 

There is one available display format for the 
Form Generator, called "oaae", and it is shown in Figure 



6.6. This 


displays 


the 


form 


in the 


actual format for 


u s e- 


time. The 


prompts 


for 


each 


block 


are shown as well as 


tholr 


associated 


entry positions. 


The " 


function" and "i/o" 


values 



of each block appear on the command line when the block is 
referenced by the cursor, 
b. Form Editing 

In "page" format the user begins with a blank 
screen and is free to move the cursor to any position and 
make entries. Form editing is a much more formal procedure 
than in any of the other applications , Entries must consist 
of a set number of parts to be accented by the system. 
First, a prompt of zero or more characters, which will 
appear on the display. 
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{user entered command) R## C## {Form Name) 



{prompt) 

Name : : Age Sex:._: 

Address : Helqnt 

: : Color Hair 



Signature J : 



Date : 



Figure 6.6 - ’’Page" format for Form Generator, 



Second, the number of spaces reserved on the form for the 
entry, which will also appear on the display. Third, a 
symbol Indicating how this entrv win be used by the form 
Generator (input, outout, call to text file, etc,). Fourth, 
t^e query statement uoon which the output is based, the 
table and field name where the input is to stored, or the 
name of the text file to be output. 

Extensive use is made of the command line while 
filling in each blocK. Only the first two parts of a block 
entry are shown on the actual form. The other two parts are 
displayed in the command line area when the block is 
referenced , 

As In previous applications the actual changes 
made during editing are not effective until the user Issues 
a "save" command. 
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c. Form Functions 

( 1 ) Arithmetic 

since the Form Generator can mai«:e use of 
DBMS queries and condition statements In acquirlnq the 
Information to complete a block, it is necessary to provide 
basic arithmetic support. The followlnq operations should be 
Included; Addition, Subtraction, Multiplication, and 
Division. These are not intended as stand alone operations, 
but for inclusion in other ooerations. 

(2) Aggregate 

As the Form Generator can make use of DBMS 
queries and condition statements in acquiring the 
information to complete a block, it is necessary to orovlde 
some aoqreaate function sucoort. The following functions 
should be Included; Total, Count, Maximum, Minimum, and 
Average, These are not intended as stand alone operations, 
but for Inclusion in other operations, 

( 3 ) Usage Indicators 

Since tne form and its blocks must be 
capable of supporting a wide range of uses, each form is 
tailor made by the user. The purpose of each block must be 
indicated by the "I/o'’ field in a manner that shows how the 
"function" block will be treated at "use" time. For 
example: The function field of an input-block might tell 
where the item is to be stored. For an output-block it may 
specify the database table and the query operation on it, 
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necessary to get the Item, For a text-block It may soeclfy 
the text file that will be Inserted In the form at that 
location , 

d. Form Commands 
Cn Find 

Used to find a block object that meets a 
specified condition by moving the cursor to Its start. The 
user Is notified if there are any more blocks that meet the 
condition. This operation requires the use of a command- 
line format, 

( 2 ) Insert 

Mew blocks are inserted by editing the 
olank area of a line In the oroper manner as described in 
Subsection (b) above. This is done in an on-screen format. 
Other forms may be inserted into the oresent form at a 
comoietely blank line, but requires the use of a command- 
line format, 

C 3 ) Move 

Used to move a display llne(s), and the 
blocks on it, to a new oositlon on the form. This operation 
reaulres the use of a command-line format, 

(4) Delete 

Used In reference to blocks, It eliminates 
the block and leaves the soace on the line blank. In 
reference to lines, it eliminates all blocks on the line, 
removes the blank line, and all lower lines move uo. This 
operation is performed in an on-screen format. 
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(5) Copy 



Used to duplicate a line, or lines, on the 
form but in a different location. This operation is 
performed in a command-line format, 

( 6 ) ^ 

Adds a blanX line, above or below the line 
referenced by the cursor. This operation is performed In an 
on-screen format. 

( 7 ) Output 

Used to send the contents of the form table 
to an indicated output device. The user can send the 
displayed version, as shown in rioure 6,6, or can oot to 
output the entire form table in tabular format so as to see 
all the information associated with each blocX. 

5 . IASS Electronic ^ail 

The Electronic Mall oacxaae supports the user in 
sending messanes to other users, for reading at a later 
time. Upon entry to the IASS the user will be promoted if 
there is mall in the mailbox, Bv entering the vail package 
the user will be greeted by a one line display synoosls of 
each message, which cannot be edited. The standard mall 
display format will be entered and the user will be free to 
read, edit, and/or delete current messages as well as 
compose new ones. Each message has a unlaue ID number and 
the user can refer to messages by the ID, originator. 
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subject, or time-stamp, Outboinq messages are actually sent 
when the user leaves the Wail application, by removing all 
messages in the user mailbox that are not addressed to the 
user and routing them to their proper destination, 
a. Mall Display Format 

There is one display format available for Mail, 
and it is called "page" format. Figure 6,7 is an 

Illustration of "page" format. Each message Is displayed on 
the screen with its fields organised in a vertical 

direction. Each field has an associated entry position that 
is desionated by delimiters. 



<user entered command) C94 Mailbox 



< prompt) » ^-Messages 

From : : ID: a# 

To : Date:_« 

Subj : : Time: — 



Figure 6,7 - "Page" format for Electronic Mail, 



b. Mall Editing 

The Mail package makes use of the standard UIM 
described in Section (A), above. The user may perform the 
standard editing functions on actual messaoes or on message 



110 



"blanlcs" 



In 



"Daqe" style display the user moves between 



messages by using the '’scroll" command. On each message the 
user may perform editing operations In any of the entry 
positions. Movement between entry positions is possible only 
by uslno cursor motion keys. 

Outgoing messages are created by editing one of 
the message "blanks" at the end of the table, or by using 
the "add" command to insert a "blank" message after the 
current one and then editing this "blank". Additionally, 
editing the contents of the "To" field in a current message, 
so that it no longer corresponds to the present user, turns 
the message into an outgoing one. 

All editing changes are not actuallv Imcleraented 
until the user Issues a "save" command. Outgoing messages 
are sent wnen the user Issues a "ault" command to leave the 
mall package. At that time the system finds all messages 
that are not addressed to the current user, updates the 
tlme-stamo on them, and then sends them to the aoproorlate 
user. Since users often have collective names, such as 
"oversight committee", that include more than one user, 
there is a special character tacked on to the standard 
destination address to indicate that the message is to the 
other users in that collective address. 
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c. Mail Functions 

C 1 ) Multi-Hat Name Designator 

A special character that is placed in front 
of a name that corresponds to more than one user name. The 
multi-hat name actually refers to a database table that 
contains the names of the users who constitute the multi-hat 
name, At use time, the system will strip the multi-hat name 
from the message, make the proper number of copies of the 
raessaoa, insert the oroper t:ser names, and send the 
messages , 

d. Mail Commands 

( 1 ) Find 

Used to move the display to the message 
that meets a certain condition (e,g. From = 'Boss', Time < 
'2 N'ov', Subj = 'Schedules'). Additionally, the user is 
notified If there are more messages that meet the condition. 

(2) Delete 

Deletes tne message being referred to by 
the cursor. To delete multiple messages it can be used in a 
command line with a condition statement, 

(3) Copy 

Given a message object it will duplicate 
the object and insert it into the mailbox, 

C4) Add 

Places a blank message above, or below, tne 
message being displayed. 
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In concluding Chanter 6 It is 



Important to 



emphasize 



that the UIM is a very 
IASS, What this chapter 
the command categories 



implemented 


by a 
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using a small 
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display and 


editing fo 
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user 
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defined In Chanter 2 
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only a suggestion. 
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VII, CONCLUSION 



The preceding six chapter have attempted to lay the 
groundwork for the oosslble design and implementation of 
what has been called an Integrated Aopilcation Software 
System (TASS), This thesis is the first small steo toward 
the study of such a system, and the majority of the work 
remains to be done. 

This thesis aporoached the topic from a broad 
oersoective and did net seek to get down to specific 
implementation issues. Instead Chapter 2 reviewed the 
aocarent characteristics of five application programs, and 
t*^e acoendices provided more detail on each. Chanter 3 took 
the character tstics of the lodcal file tyoe associated with 
each application and formed them into a common data object. 
Chanter 4 took the common data object and exolained a set of 
operations on it. Chapter 5 described how each of the 
included aoolicatlons might interface to the common data 
object by using the operations of Chapter 4, Lastly, Chapter 
6 attempted to Illustrate how the user would Interact with 
the applications in the IASS through a common interface. 

One point must be emphasized and it is that an IASS is 
not a relational Database Management System (DBMS). There 
are enough DBMS applications already proven and available on 
the market. See Appendices (E) and (F) for two examples. 
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What the IASS does is try to use the DBMS approach to 
invisibly support the user's effort to utilize the various 
and unioue applications. The IASS conceptual level is a 
common bond between all Included applications and while it 
is the heart of the system, it should be kept hidden from 
the user, except in specialized applications like the DBMS, 

If the user is always qlven direct access to the 
conceptual level and its operations, then the Iass is 
nothing more than a DBMS, In fact, such a capability is 
already present In the DBASE II system. Appendix (S), 
although It would be greatly improved by incorporating some 
of the better presentation ideas from the SEOUITUR system, 
Appendix (F). 

It must oe empnaslzed that this thesis is a limited, and 
very subjective, view of the IASS, From the studv of this 
hypothetical IASS it seems clear that such a system could be 
imolemented. However, no soeclflc estimation can be made on 
the effectiveness or efficiency of such a system. It would 
be reasonable to expect the efficiency to be less than that 
of the Individual application packages, but there is no way 
of determining how much less. These are very important 
considerations and win have to be studied before the true 
usefulness of an TASS can be estimated. 

Much effort was placed on the conceptual level of the 
IASS, and yet It seem certain that the user interface will 
be the oortlon of the IASS that will determine its success 
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or failure as an actual system. It is important to define 
the ultimate ooals of an IASS In realistic terms so that an 
measurable objective exists. After some study there apoear 
to be two Important coals In the IASS desiqn. 

The first is to reduce the cost of owning the separate 
application oroorams by combining them Into one IASS, Since 
It has been shown that the five olven applications have much 
in common that can be factored out and placed in a common 
conceptual level. It would appear reasonable to expect the 
same from any future applications accepted for Inclusion, 
This common conceptual level reduces the amount of 
duplication necessary to "own" the individual applications, 
Economic savlncs would hopefully be realized from the 
smaller amount of code needed, its more uniform structure, 
and the sharlno of capabilities between applications. The 
design of the conceptual level and the individual 
application oac'caaes will have the major effect on achlevino 
this acal. 

The second coal is tnat the user must perceive an 
improvement in using the IASS over using the separate 
applications. The IASS must be more "user friendly" than 
the disjoint application programs it replaces. Simplicity 
and capability must be emphasized over system 
sophistication. Each capability that will be Incorporated 
In an application must be measured as to Its complexity and 
usefulness. It Is not justifiable to Increase system 
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complexity just to add a fancy but little used feature. The 
design of the user Interface module and the individual 
aPDiicatlon packaoes will have the major effect on achlevinq 
this goal. 

It would apoear to be too early to attempt the 
implementation of such a system. Instead, more investigation 
needs to be done and the objectives more tightlv defined. 
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APPENDIX A: WORD STAR 



WORD STAR is a word processing program developed by 
Micro-Pro to combine the capabilities of a screen editor and 
an on-screen text formatter. The result is a very powerful 
text editor which displays the referenced file as it will 
appear on the printed oaae. 

WORD STAR is orlmarllv menu-driven. The commands which 
are presently valid are displayed in a menu, and are 
executed by Keystroke combinations, on-line information Is 
available to the user concerning many other aspects of WORD 
STAR. The menu driven feature eases user initiation to word 
STAR and is part of the Heir facility. The level of help is 
selectable to match the users level of experience, and 
determines the extent to whlcn the menus are displayed on 
the CRT. 

WORD STAR is composed of a set of seven hierarchically 
organized menus or environments, as shown in Table A.l. The 
user enters WORD STAR in the No-Flle environment. At this 
point there is no file in reference, the object granularity 
is the file, and the menu options Include commands to: 
change the logged disk drive, set the automatic directory 
dlsoiay feature (on/off), set the help level, print a file, 
rename a file, copy a file, delete a file, run a program, 
open a document file, and open a non-document file. 
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Table A,1 - WORD STAR Menu Hierarchy 



LEVEL 


MENU 


1 


No File 


2 


Main Menu 


3 


a. Help 




b. On-Screen Format 




c. Print Control 




d. Quick Edit 




e, Fll^/Block 



WORD STAR recognizes two types of files, "document" and 
"non-document", a document file can either be a text file 
processed by a word processor or a program run by a 
comnuter. A non-document file is a soecial ouroose file 
which is used by another software product, and will not be 
discussed further. 

The on-screen editor and formatter are invoked by 
selecting the menu option to open a document file. This 
causes WORD star to enter the Main Menu environment with a 
specific file in reference. If the file previously existed 
it is made current, otherwise a new file is created and made 
current. On entering the Main Menu environment, a status 
line and a rule are Initialized. The status line contains 
information about the system - the name of the file, the 
page within the file, the column and row number the cursor 
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is at, and the Insertion mode (on/off). The rule indicates 
the right and left margin position as well as the tab 
positions. The Main Menu represents the basic file editing 
environment where the user will remain until it is decided 
to quit the current file and return to the No File Menu or 
the operating system. In any case, WORD STAR does not 
permit lateral movement between the sub-menus of the Main 
«enu . 

A useful feature word STAR employs Is "word wrap". With 
word wrap, the user does not have to insert carrlace returns 
at the end of each line. As the text overruns the end of 
the line, WORD STAR automatically starts the next line. In 
this wav, the user merely Inputs an entire blocv: of text as 
a continuous ASCII character strino, and leaves the 
formattlno to the system, in the Main Menu, the user can 
edit the file in oranular Ities of character, word, and line. 
Insertion Is a "togoled" ooeratlon Con/off), wn*>re the user 
is either in insert mode or overwrite mode. Any keystroke 
entered is either inserted in the text at the cursor 
position, shifting characters to the rloht to accommodate 
it, or overwrites the character at the cursor position. To 
facilitate on-screen editing, the Main venu contains 
commands to control cursor movement and to scroll the 
screen. It is possible to insert tabs or end-of-paraaraoh 
markers. There is a "Find and Replace” command which can be 
repeated any number of times. Deletions can be done on a 
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sinale character, a word, or an entire line. The f^aln Menu 
also contains options to select one of the five submenus. 

The Quick Editing environment supports edltlno on hloher 
levels of abstraction of text objects than the Main Menu, 
There are additional cursor movement commands to give a 
wider range of control and granularity. As In the Main Menu 
environment, the user can scroll the display, but now it Is 
continuous at nine user selectable rates until stopped by 
command. Insertions are accomplished in the same way as In 
the Main Menu environment, but deletions are possible on a 
wider range of objects. There is a feature to allow a 
command to be repeated at one of nine user selectable rates, 
until stooped by command. 

The Block environment provides the user a set of 
operations on a block of text, wood star considers an 
entire file to be a special case of a block of text. Files 
can be saved by several menu options: save and resume the 
referenced file, save and quit to tne operating system, save 
and exit the referenced file, and copy to anotner file. 
Files may also be renamed, deleted, printed, or cult without 
saving chances. To supoort these file operations, the Block 
Menu contains options to change the logged disk, and to turn 
the automatic directory listing on or off. In this 
capacity, the Block environment is used as a successor to 
the Main or Quick Editing environments after tne cursor is 
positioned. Blocks In a file must be marked by the user. 
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As a delimited aggregation of text, a block can be moved 
within the same file. Copying blocks of text can either be 
within the referenced file or between the referenced file 
and an external file. Block cooylnq between files are bi- 
directional, Copying a block to an external file entails 
overwriting an existing file or creating a new file, 
CoDving a block from an external file entails moving the 
entire external file to the point In the text indicated by 
the cursor. Any marked block can also be deleted. As a 
precautionary measure, wcRD STAR allows the user to hide 
block markers, and only blocks which are visibly marked can 
be deleted. In addition to a text block being organized 
Into a continuous, unstructured string of text, WOPD STAR 
supports a columnar oroanization. 

The previously described menus contain operations to 
create, edit, position the cursor, or output a text file. 
The format of the file, either as it is visually displayed 
or printed out, is defined by a set of formatting oarameters 
associated with the file or by commands embedded in the 
file. The formatting oarameters associated with a file are 
initially set to default values and the set of embedded 
commands is initially empty. 

Formatting In WORD STAR is primarily done on-screen with 
the options contained in the On-Screen Menu. The on-screen 
formatting commands are those whose effects can be visually 
dlSDlayed, and they are listed In Table A, 2. 
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Table A, 2 - WORD STAR on-Screen Formatting Commands, 



1. 


Set left 


margin 


2. 


Set right margin 


3. 


Release 


marolns 


4. 


set and 


clear tabs 


5. 


Indent a 


paragraph 


6, 


Create a 


special rule 


7. 


Center text 


8. 


Set line 


soaclng 



The On-Screen Menu also contains options In the form of 
(On/Off ) tooqles to control; word wrao, rule display, 
variable tabbinc, hyphenation help, right margin 
lustlf Icatlon, soft hyphen, print embedded control 
characters, and page brea:< disolay. If an on-screen 
formattlna operation needs to be applied to the previous 
contents of the file, the applicable portion of the file 
must be reformatted. Furthermore, these formatting 
parameters are only temoorarlly applied when the file Is 
referenced. Any subsequent reference to a file regulres 
that the on-screen formatting parameters be reset. 

WORD STAR combines Into one menu, tne Print Menu, all 
options which create special printing effects net normally 
dlsolayable on a video screen. There are options to; bold 
face, double stri>ce, underline, strike out, subscript, and 
superscript. Since the effects of these ootions cannot be 
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displayed on the video screen, a special character Is used 
to ruark the affected area. Additional special printing 
effects are selectable throuoh this menu on a one time 
basis; overorint a character, Indicate a non-break space, 
and overorint a line. The Print Menu also contains options 
which control the printer during output. The user may embed 
commands In the text file to cause the printer to change 
pitch, or cause a pause to allow the user to change the 
print element or ribbon. 

Printing can also be directed through the use of 
embedded dot commands. These commands are placed In the 
text file and aooear as regular text on the disolay, but are 
not output to a orlnter and force wnoo STAR to chang<» a 
printing parameter at print time. Dot commands alter the 
default carameters word STAR uses to format the printed 
page. Table A, 3 provides a listing of these commands. 

Dot-commands may be placed anywhere In the text, but 
since they are static and tend to destroy the relationship 
between what Is displayed and what is printed, they are 
usually oiaced at the beginning of the text file. As with 
the options of the Print Menu, dot-command actions must be 
supported bv the specific orlnter in use. 

The last menu to be described is the Help Menu, Help is 
"on-line'* In that it can be invoked at any time through the 
Main Menu, and Is "dynamic" in that the level of help can be 
adjusted. The level will determine how much Information Is 
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displayed when an option is selected. The Help Menu options 
display information on: paraoraph reformlnq, flaps in the 
right-hand margin, dot and print commands, status line, 
ruler line, how to set margins and tabs, and how to move 
blocks of text. 



Table A, 3 - WORD STAR Dot Commands, 



1 . 

2 , 

3 . 

4 , 

5 . 

6 , 

7 . 

8 , 
9 . 
10 
11 
12 
13 



set line height 
set page length 
Set too margin 
Set bottom margin 
Generate headers 
Generate footers 
Set footer margin 
Reset page number 

Offset page from left side of printer 

Position page number 

set character width 

Force a oage break 

Prevent a cage break 



WORD STAR is an excellent and very popular word 
processing program. The screen-oriented and on-line 
formatting features are different from other systems in that 
they are extremely easy to use. Once experience is gained 
with WORD STAR it is difficult to use line-oriented editors 
or off-line formatting systems. The on-line help facility 
makes WORD STAR easy to learn and user friendly. One aspect 
of WORD STAR that could be considered a disadvantage is the 
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large command set. Howeverr being menu-driven, the 
not normally used do not have to be memorized since 
always listed in the menu. 



commands 
they are 
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APPENDIX Bt VI 



'•VI" is a text editor used by the UNIX operating system 
and was created by the University of California at Berkeley, 
and Bell Laboratories, 

VT (visual) Is a display oriented interactive text 
editor with a command vocabulary size of about ninety one. 
The user sees the CRT screen as a window into the text file 
and all editing operations are immediately visible. Line 
numbers are not disolayed and have no real use In vi, 
although it is possible to find out the number for a line. 
For the saXe of protection the user does not actually edit 
the file, but a copy of it. At the completion of a session 
the user will indicate whether to keen the edited cocy or 
the original. 

There are forty seven movement commands for control of 
the cursor, which is the editor's point of reference, and 
the screen display. Scope of movement is possible over 
file, screen, oaraoraph, section, sentence, line, word, and 
character sized units. Up to twenty six locations in the 
file can be marked for later return, or soeciflc locations 
found that match a desired character string. Table B.l 
lists the cursor movement commands available in the vi 
system. Note that there is duplication, in that more than 
one command does the same thing. 
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Table B.l 



VI Cursor Movement Commands 



1, Backward window 

2, Forward window 

3, Scroll down » 

4, Scroll up ♦ 

s. Baocspace one character ♦ 

6, 0ac)cspace a single character 

7. Backup a word 

3, Backuo a word during insert 
0. Backuo to beninninq of word 

10, Betreat to orevious line * 

11. Retreat to beginning of sentence 

12, Retreat to beginning of previous paragraph 

13, Retreat to previous section boundary 

14. Linefeed advance to next line 

15. Advance to first non-white soace on next line ♦ 

16. Advance to next line/ first white soace 

17, Advance to next line, same column * 

13, Advance to next character ♦ 

Id, Advance to beginning of word 

20, Advance to end of next word 

21, Advance to section boundary 

22, Advance to the next tyoed character 

23, Advance to beginning of next paragraph 

24, Move to previous line * 

25, Move to end of current line * 

26, vove to balancing parenthesis or brace 

27, Moves cursor to last line on screen * 

28, ^'oves cursor to middle of screen * 

29, V(3ve forward to beginnino of word 

30, Wove forward to end of word 

31, vgve to first non-white space on current line 

32, vove to line number 9 * 

33, Search for word ♦ 

34, Search forward for string ♦♦ 

35, Search backward for string * 

36, Search for next match ** 

37, Repeat last single character search 

38, s*lnd a single character, backwards ♦ 

39, Find a single character, forward ♦ 

40, Reverse direction of previous find 



*, ♦♦ Useful 



see page 133, oaragraph (4) 



Table B.l 



CCont, ) 



41, Find first Instance of next character 

42, Repeat the last search command ♦ 

43, Homes the cursor 

44, the present position of the cursor ♦ 

45, Return to mariced position ♦ 

46, Redraw the screen 

47, Returns to previous context 

* Useful - see paqe 133, paragraph (4) 

The operations of Insertion, modification and deletion 
are supported by thirty commands that permit the user a 
varied level of object control. Items that are inserted, 
modified or deleted are immediately updated on the screen to 
give the user a current view of the file status. The user 
also has the ability to undo the previous command if Its 
effects were undesired. Most Insertion and modification 
commands are structured so that they continue to operate 
until the user issues a command to terminate them. Normally 
durino insertion the user has control of format in that new 
lines are started by entering a carriage return. However 
there is an option that will let VI determine when to start 
a new line, based on line length, and let the user just 
enter text as a continuous stream. Table B.2 lists the 
thirty edit commands. 

In order to use VI the user issues the command "vi" 
followed by the name of the file to be edited. If this is a 
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new file, then the name will not be found in the directory 
and VI win create an empty file. After entry, the user will 



Issue cursor motion commands to maneuver through the 
and Issue edit commands to change the contents of the 
There are no other modes or displays available in VI. 



Table B.2 - VI Edit Command Summarv 



1. 

2 . 

3. 

4. 

5. 

6 . 
7. 

9 . 
Q. 

10 . 
11 . 
32. 
1 3. 

14. 

15. 

16. 

17. 

18. 

19. 

20 . 
21 . 
22 . 

23. 

24. 

25. 

26. 
27. 
23. 

29. 

30. 



Insert a number of soaces 
Insert nonorintabie characters 
Insert ” shlf twidth " blank soaces 
Insert at the beginning of line 
Insert at end of line 
Insert before the cursor ** 

Insert after the cursor *♦ 

Insert new line below current line 
Insert new line above current line 
Insert text below current line ** 

Insert text above current lin#* ** 

Delete last character 

Delete rest of the text on current line * 
Delete character before cursor 
Delete the following object 
Delete single character under cursor ** 
Repeat last command ** 

Join together lines * 

Reolace single character under cursor 
Peolace characters at cursor ** 

Change the entire line 

Chance single character 

Change the following object 

Change rest of the text on current line 

Undo last change to current buffer ** 

Restore current line to orevlous condition 

Yank following object Into buffer ♦ 

Yank a copv of current line into buffer 

Reoeat last text insertion 

Named buffer specification follows * 



♦, Useful - see pace 133, paragraph (4) 



file, 

file. 



130 



In addition to the two command categories already given 
there are additional commands of a miscellaneous nature. 
Table B,3 lists these additional commands. 



Table B,3 - Miscellaneous vi Commands, 



1, Print file status message 

2, Clear and redraw the screen 

3, Pedraw the current "logical" screen 
<1, suspend or restart outcut 

?, Cancel oartlallv formed command 

6, Return to position In last edited file 

7, Reformat lines in buffer 

R. Indicate file and option manipulation 
9, Quit VI, enter line-oriented editor 



Some very basic formating commands for line length and 
indenting are directly available, A macro creation 

capability Is present to allow the user to create 

abbreviations for command strings. Table B.4 lists these 
formatting commands, vi makes no claim to supporting a 
f ormattlno package , since the file will be output in the 
same format the user entered it. For special formatted 

output a VI generated file must be processed by an off-line 
word processor, like "NROFF -ME" described in Appendix CD), 
VI provides a hloh degree of support to the user for 
restructuring a file, or flies. There are nine buffers 
available for storing deleted text, and twenty six buffers 



131 



to use as temporary holding spaces while reordering and 
editing. The text can be taken from other files and/or 
buffers, for use In the file currently being edited. If 
needed, previously deleted text from the current file can be 
recovered, and also other files. 

Table B,4 - VI Formatting Commands, 

1, Reformatting command 

2, Shift lines left one "shif twldth" 

3, oelhdent lines 

4, Shift lines right one "shlf twldth" 

5, Prints current file contents 



"VI” Is a good screen oriented editor and has a wide 
range of capabilities, however it has some drawbacks, 

(1) It has a poorly designed user Interface since the 
command vocabulary Is very laroe and the individual command 
strings are difficult to remember. There does not seem to 
have been much thought given to the design of the command 
vocabulary, 

(2) It takes a fairly long time to learn the vi system 
and gain functional use. An on-line tutorial program is 
used to help beginners, since it is hard to become familiar 
with it on their own. 
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(3) VI does not Inspire user confidence in that it is 
too easy to accidentally enter some unknown command strinq, 
and there is little correlation between what the user wants 
to do and the coromand(s) that must be issued, 

(4) From personal use, about thirty three commands were 
considered to be oenerally useful (marked by ♦ or ♦*), and 
only ten of these accounted for tne qreater majority of all 
ooerations (marked by **), The remalnino vi commands were 
qenerally treated as "window dressinq" by all but the most 
sophisticated users, 

(5) There Is no help facility# of any kind, provided by 
the VI system. At the very least, an on-line llstlnq of 
commands should be orovlded. 
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APPENDIX C: EDIT 



EDIT Is a text editor supported by the UNIX operating 
system. EDIT is a simplified version of another UNIX 
editor and contains a minimal set of operators. It Is line 
oriented which means that the main object of EDIT is a line 
of text of some finite length, 

EDIT merely supports text file creation and modification 
operations. The user Inputs text into a file by lines, 
Indicatino the end of a line bv a carriage return, A 
display of the file win show an ordered list of lines as 
they exist in the file. Ordering of lines is completely 
determined by the system ard although the user can use line 
numbers as a reference, the line number is not directly 
accessible to the user to change or set. Any display of 
text by EDIT is done by line. Substrings can be referenced 
within a line, or lines, A formatted output display by EDIT 
can only be achieved if the user directly inputs the desired 
format line by line. No processing of the contents of a 
line is done by EDIT, 

When invoked, EDIT sets aside a temporary cooy of the 
referenced file in a working buffer. If the file does not 
already exist in the directory, then it is a new file and is 
created. The basic set of commands available to EDIT are 
listed in Table C,l. 
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Table C,1 - EDIT Command summary 



1. 


Edit a file 








2. 


Specify a file 








3. 


Append llne(s) 








4. 


Insert line(s) 








5. 


Insert llne(s) into 


an 


external 


file 


6, 


Insert line(s) from 


an 


external 


file 


7, 


Delete line(s) 








8. 


Copy line(s) 








9. 


Move llne(s) 








10, 


print line(s) 








11 , 


Show line number 








12, 


List llne(s) 








13, 


substitute a string 








14, 


Search for string 








15, 


Undo last command 








16, 


Make effect of command 


global 




17. 


Move cursor 

- forward 

- backward 








13, 


Quit 









Searching for a line has the effect of makina the found 
line the current line. Any subsequent editing ooerations 
are done in relation to the current line, Lines can be 
found and disoiayed by line numbers, and ranges of lines can 
be specified. Lines can also be found and disoiayed forward 
or backward, relative to the current line, a line can be 
found by any substrino of its contents, but the entire 
substring must be contained in one line, because of this 
deficiency a substring may not be locatable merely because 
it exists in the text file. When searching EDIT will move 
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forward or backward and will wrap around tne buffer, 



so as 



to return to the startlnq line if the target object is not 
found. 

New lines can be appended before the current line, or 
inserted after it. The user issues a command to specify that 
there are no more lines to add. Upon completion the current 
line is the last line added. Additions can also be made hy 
moving or copying lines within the text file. Moving can be 
viewed as a combination of a deletion and an insertion. 9v 
specifying a range of lines to be chanced, they are deleted 
and the system enters Insert mode for the user to add the 
new lines. Additionally, insertions are possible from other 
text files. 

Modifying a line is done bv substituting a new string 
for an already existing target string on the lino. If 
desired, the substitution can have global effect in that it 
will modify all occurrences of the target string on all 
lines , 

Deletion Is usually accomplished by Indicating the line, 
or lines, to be deleted, A search command can be used with 
the deletion operation wnen the soeciflc line numbers are 
not know. 

EDIT protects the user from making inadvertent changes 
to a text file. The effects of the last executed command 
that effected the buffer car. be reversed. Additionally, the 
effects of the editing session do not become permanent 
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unless the user Issues a command to make them permanent. At 
that oolnt the edited copy, which is in the buffer, replaces 
the oridlnal file in the directory. Leavino EDIT without 
Indicatlnct to make the changes oermanent is like the editing 
session never occurred. 

In addition to writing a whole buffer out to the 
directory, subparts can be written to another text file. 
This is done by specifying the range of lines and the file 
to be written to. 

The EDIT text editor Is very basic which Is both an 
advantage and a disadvantage. It has a minimal command set 
and therefore is easy to learn. The biggest oroblem is that 
it is line-oriented. As such, modifications are done a line 
at a , time, wnere each line Is a separate entity. It does not 
treat the file as a whole, but as a disjoint collection of 
lines. It Imposes the idea of line numbers, which do not 
exist in the text file, in order to use the editor. There 
are fewer high level editing operations available, as 
compared to current screen-oriented editors, and they are 
limited to operating on lines and not the text file as a 

I 

whole. While capable of producing satlsfactgry results, due 
to its line at a time limits, the operation becomes tedious 
if the file is large, and/or there are a lot of small 
changes which must be done. Given the advanced features of 
todays line-oriented editors, EDIT is a very archaic and 
frustrating way to create and modify a text file. 
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APPENDIX D: NROFF •»£ 



”NROFF -ME" is a text processing facility for files that 
are created on the Unix operating system. It was created by 
the University of California at BerKeley, and Bell 
Laborator las , "NROFF" is a orooram that accepts an input 
file creoared by the user and cutouts a formatted caper to 
the user's design, "-ME" is a macro cacKaoe that enhances 
the capabilities of the "NROFF" program by adding additional 
formatting abilities and commands . The input file consists 
of the actual text entered by the user, through some editor 
system, and a series of embedded NROFF -ME commands. 

There Is a large vocabulary of "recuests", which are 
really dot-commands consisting of a period folio w'ed py a two 
letter string. The basic NROFF pac'oge sucoorts seventeen 
cateoorles of commands, and has a total of eighty seven 
commands. The -me pacicage adds three categories and a total 
of sixty commands for a grand total of one hundred and forty 
seven commands. Table D.l lists the NROFF and -me command 
categories, and the number of commands in each, 

Npoff -me uses thirteen predefined general variables and 
twenty three predefined read-only variables to support its 
processing needs. The user is provided with a macro 
facility to define new commands in terms of the basic set of 
commands and operations on the variables. This allows the 
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user to abbreviate a fairly long command stream into a 



single command. 



Table D,1 - NROFF and -ME Commands, 



COMMAND CATEGORY 


COMMANDS 

NROFF 


-ME 


1. Font S Character Size Control 


7 


9 


2, Pace Control 


7 


0 


3, Text Filling, Adjusting R Centering 


g 


0 


4, Displays 


0 


22 


5, Vertical spacing 


7 


0 


6, Line Length & Indenting 


3 


0 


7, Paragraphing 


0 


4 


8, 'Macros, Strings, Diversions, & Traps 


13 


0 


9. Number Registers 


3 


0 


10, Tabs, Leaders, ;; Fields 


4 


0 


11, InoutOutPut Conventions 


Q 


0 


12, Hvonenation 


4 


0 


13. Titles 


3 


1 3 


14, Headings 


0 


6 


15, Line Numbering 


2 


0 


16. Conditional Input 


3 


0 


17, Environment Switching 


1 


0 


13. Standard Input Insertions 


2 


0 


19, InoutOutput File Switching 


3 


0 


20, Miscellaneous 


5 


6 


TOTAL 


87 


60 



NROFF -ME is a good word processing system and it can 
produce some complex formatting actions. However, it does 
suffer from some drawbacks, 

(1) Since the file is first created by the text editor 
and then run by nrofF, the user has a significant delay in 
determining if the desired format was achieved. 
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C2) In addition to deoendlnq on the text editor. 



NROFF 



must depend on other programs to preprocess the text file 
before nrOFF can handle it for specialized reauests. Two 
examples cf preprocessors are pacKages to handle tables and 
comolex eauatior symbology. While enhancing ^•JROFF -ME's 
capabi lltles , they add more categories and commands, and 
increase the amount of time necessary for the user to see 
the actual results of commands, 

(3) The user manual for the NROFF pacxaoe is not 
presented in sufficient detail to completely understand the 
effect, or use, of all commands. It appears that the user 
is supposed to have a basic understanding of the system 
before readinc the manuals! 

(4) The command vocabulary is fairly large and they are 
not easy to remember. Based on personal use, only about 
twenty percent of the vocabulary is generally useful and 
therefore remembered. Table D,2 presents a simplified 
listing of the most used commands. 
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I 




Table D,2 



Basic Commands MROFF -ME 



1, Page length 

2, Line spacing 

3, Line length 

4, Page headers 

5, Indent 

- oermanent 

- temoorary 

6* Pegin next cage 

7, Meed # lines 

i?. Insert * blank lines 

9, Center the next # lines 

10, Break 

11, Define a macro 

12, Flll/No-flll 

13, Hyphenate/No-hyphenate 

14, Underline 

15, Sectlon/Chaoter headings 

16, Quotations 

17, Footnotes 

19, Keep an index 

19, start oaravoraph 

- basic 

- left adjusted 

- body Indented 

- numbered 

20, Start display 

- list 

- block 

- floating block 

- delayed text 

21, Table handler ♦ 

- definition 

- start 

- body 

- end 

22, Equation definition 

23, Multiple column format 

24, Default paper formats 

- thesis 

25, Control constructs 

- read special variables 

- change special register 

- conditional formatting 



* part of Table preprocessor 
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APPENDIX E; DBASE II 



DBASE II Is a relational database system created by 
Ashton-Tate of Los Angeles, California for microcomputer 
systems. For this review, the CP/M version of DBASE II was 
used, where the DBASE II program is an executable "command 
file" residing In the system. 

The DBASE II system utilizes several different file 
types; database, report form, command, index, memory, and 
text. Each file tyoe has a specific purpose that is 
identifiable by its tvoe name, "Report form" files store the 
information, specified by the user, for describlno the 
format (headings, fields, totals, subtotals, contents, etc,) 
in which a "database" file Is to be output. "Command" files 
contain a seauence of DBASE II statements, commands, and 
control structures necessary to create a user defined view, 
"Index" files are a list of pointers to a specific 
"database" file, "Memory" files contain the values of 
memory variables and constants saved previously by the user, 
"Text" files are collections of ASCII characters for input 
into a "database" file, or created by output from a 
"database" file, DBASE IT cannot directly use "text" files. 
Most of the files are stored in what is Known as Standard 
Data Format (SDF), and they can be used directly by any 
other program that uses SDF files. Additionally, any text 
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files in SDF can be used by the DBASE II system 



The file 



is the largest data object supported by DBASE II which 
creates, deletes, or modifies the current flle(s). A 
database file is brought into reference by user 
specification, and a maximum of two database files can be 
"open" at one time, 

DBASE II can be used interactively or can be programmed 
to create a view of the database to supoort recurring 
applications. Regardless of method, DBASE II orovldes the 
user with the same basic high-level data definition (DDL5 
and data manipulation CDML) language. An English ll'<e 
command language with a very regular syntax Is a user 
friendly feature of DBASE II, The commands are very 
powerful in that their ooerands and results are typically 
database files. The command structure is usual Iv presented 
In the following form: 

COMMAND [SCOPE] [CONDITION] 

The scooe modifier designates the number of records to 
be selected in response to the specific command. The 
condition modifier specifies a conditional statement that 
the record's field values must satisfy In order for the 
record to be included In the final result. Table E.1 
provides a listing of the basic DBASE II commands, with 
duplicate commands having been factored out. 
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Table E,1 



DBASE II Basic Commands 



1. Display an expression on the screen 

2. Format screen or printer output 

3, Input a character strlna 

4, Input a string to a memory variable 

5. Walt for user inout 

6, List the records In a database 

7. Display data from a database 

8, Display the structure of a database 
•3, 9enane a file 

m. Erase a file 

11. Generate a report 

17 , Execute a "command" file 

13, Return from a "command" file 

14, Display the contents of the memory variables 

15, Store a value In a memory variable 

16, Save memory variables to a file 

17, Restore memory variables from a file 

18, Select a specific database for use 

19, set specific DBASE ll parameters 

20, Abort a command 



21, Create a ne» database 

22, Edit a database 

23, vodlfy a database's structure, or the 

contents of fields in selected records 

24, Update a database from another database 

25, Add data from a text file to a database 

26, Copy data from a database to a text file 

27, Insert record(s) into a database 

28, Delete record(s) from a database 

29, Unmari^ records mar'ced for deletion 

30, Locate a record based on key value, 

or condition 

31, Goto a specified record 

32, Move forward or backward in a database 

33, Index a database 

34, Sort a database based on a field 

35, Perform join operation on two databases 



36, Count the number of records 

37, Sum a field or subfield In a database 
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Default ordering for records In a database file is the 
sequence in which the records are entered. Ordering can be 
altered by inserting records into specific parts of the 
database, and by sorting or Indexing the database, in the 
default order, the "database” file does not contain a 
recognized key, 

Sy sorting or Indexing a "database" file, keys are 
defined and the search time required to locate a record is 
reduced, ^ultirle indexing be done for the same database, 



but based 


on 


different 


keys . 


Sorting 


produces 


a new 


"database " 


file 


, which is 


a copv of 


the 


original database. 


only it is sorted. An 


"Indexed" 


file 


is 


a virtual 


file of 


oolnters to 


the 


original 


"database" 


f lie . 


Whereas 


lookup 


soeed can 


be 


enhanced 


by indexing 


a 


database , 


there is 



overhead Incurred in maintenance of the "index" file. 
Changes made to the original database file are not reflected 
In the new sorted "database" or "index" file. The orlolnal 
database must be sorted or Indexed after each change in 
order to remain current. 

The data definition lanouage allows the user to define 
the organization of the data in a new database file by 
soecifylng the name of the database, and giving information 
on each of its fields (name, tyoe, width, decimal olaces). 
The structure of a new database file can also be copied from 
that of another database file. Additionally, new structures 
can be created as the result of using the join operator 
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provided by the DBASE II system. At any time, the structure 
and/or contents of a file can be displayed or output. The 
structure of a database file can also be modified at a later 
time, but presents some problems in that all records 
currently in the database file are destroyed. 

Besides usino DBASE II interactively, it can be 
proarammed in its own lancjuaqe throuch the use of "command" 
files. The OMfj statements are embedded In the file and 
Iterative execution of DML statements are controlled by a 
set of DBASE II control structures (If-Then, I.f-Then-£lse, 
Goto, and Do-While). "Command" files tend to make extensive 
use of memory variables and Input/output functions which are 
also extensively suooorted by DBASE II. To create a user 
view the des Icner/proor amraer will edit a "command" flleCs) 
to contain the correct DBASE II statements, commands, and 
control structures to manipulate the proper "database" 
files. The capabilities and limitations of any view is 
dependent on the desion of the "command" flleCs), 

The reason for the great popularity of DBASE II is that 
it is a very easy database management system to learn and 
use. Its Enqllsh-lllce command language is natural and user 
friendly. Although the command set is rather extensive, the 
command names accurately describe their action and use a 
regular syntax so they are easy to remember. The 
interactive nature and full screen dlsoiay orientation ma!<es 
user interaction simple and direct. with its set of 
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predefined functions, input/output commands, "command" 
files, and progranmlng constructs it is easy to create views 
for almost any apolication, DBASE II is a powerful 
relational database svstem yet it is obvious that the 
designers gave much thought to iceepina it simple and did not 
introduce comolexlty for its own sake. However, there are a 
couple of oroblems with DBASE IT which are worth mentioning, 
and they are all probably due to the justified emphasis on 
simplicity, 

(1) At any one time, a maximum of two databases can be 
in reference. This limitation requires that databases be 
explicitly brought into and out of use. It would helo if 
there was another method, besides using a "command" file, 
for oerformlno ooeratlons cn multiple tables. 

(2) In modlfyina the structure cf a database the 
contents are deleted. This requires that the database be 
explicitly saved to an external database and then be 
recopled back after structure modification. It is an 
inconvenience, to say the least. 

(3) The only relational operation directly provided by 
the system Is the JOIN command. It would greatly enhance the 
capability of the system to provide more of the operators, 

(4) The disDlay structure is a little bit too rigid, 
and the user does not have much direct control, sort of 
writing a "command" file, to effect the output format. 



APPENDIX F: SEQUITUR 



SEQUITUR is a relational database system desiqned by the 
Pacific Software Manufacturing Company of Ber’<eley, 
California , 

SEQUITUR sees a database as a collection of named 
tables, each of which contains some kind of data r'^laced to 
the subject of the database. Each database has a set of 
system tables. The "Column" table lists the name, tyoe, 
size, and disolay format of all columns authorized for use 
in the database's tables. The "Table" table lists the names 
of the columns that are Included in each of the database's 
tables. Together the "Column" and "Table" tables act as 
oart of a data dictionary system for the database. 

SEQUITUR has a fairly laroe command vocabulary of over 
sixty seven commands. There are twenty five basic commands, 
forty two screen editor commands, and more formed by 
combinations of the previous commands. A multilevel "Helo" 
facility is used to supoort the user. 

SEQUITUR offers four kinds of help. There are status 
lines at the too of the screen. An "edit card" display can 
be called by the user in order to see a comorehens Ive list 
of cursor object and motion keys, and escape ooeratlons. 
The "help" command summons an on-line manual, that is preset 
by the user to provide no, medium, or maximum helo. Lastly, 

14fl 



there are situational help prompts that occur during the 



command process. 



Table F,l - SEQUITUR Basic Commands, 



1. 


CHOOSE {database) 


2. 


CREATE {database) 


3. 


add to {table) 


4. 


EDIT {table) 


5. 


SMOW {table) 


6 . 


PRINT {table) 


7. 


REPORT generator 


8, 


F0R“S generator 


9. 


SELECT from {table) ♦ 


10. 


manual select 


11 . 


JOIN {tables) 


12. 


SORT {tables) » 


13. 


UNION * 


14. 


intersection * 


15. 


DIFFERENCE * 


16. 


UNIQUE rows * 


17. 


DUPLICATE rows * 


18, 


COPY 


19. 


APPEND 


20, 


RFVCVF rows 


21 . 


rename column 



22, COMPACT base 

23, DUMP to {file> 

24, LOAD from {file) 

25, HELP from manual 

26, EXIT 



* = Member of SEQUITUR's 

"set" commands. 



The twenty five basic commands cover the 
operational capabilities of the SEQUITUR system 
commands are oresented to the user in the form of a 



major 
The 
menu , 
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and once 



a choice is made SEQUITUR enters the display mode 



necessary to support that choice. Table F.l lists the basic 
commands, plus the command for exiting from SEQUITUR, 

The SEQUITUR display modes are organized as "tables", or 
"pages". The table mode is similar to the approach taken by 
the "Query-by-Example" system (QBE), and Presents the data 
in columns and rows with vertical lines senaratlng the 
columns and indicators for new rows. Alternatively, the 
page mode presents the data one row at a time, with the 
column headings listed vertically. The user has the ability 
to flip back and forth between the two display modes at 
will. 



Table F.2 - SEQUITUR Cursor Object s, Motion Commands. 



1 . 

2 , 

3. 

4. 

5. 

6 . 
7. 
3. 

9. 

10 . 
11 . 
12 . 

13. 

14. 
1 ?. 
16. 
17. 



Move cursor up one line 

Move cursor down one line 

Move cursor left one object 

Move cursor to next object 

Move cursor to beginning of o 

Move cursor to previous word 

Move cursor to end of current 

Move cursor to next word 

Object = word 

Object = line 

Object = sentence 

Object = paragraph 

Object = view 

Object = pace or screen 

Object = column 

Object = row 

Object = one character 



b ject 
object 
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Once In a desired display mode the user must maxe use of 
the editor commands to maXe changes to the table. All editor 
commands are single Xeys combined with the <Control>, 
<Escaoe> , or <Tab> keys. Table F.2 provides a list of the 
cursor object and motion commands available. Most 
operations require two commands since the object must be 
specified first, and then the actual operation. 



Table F.3 - SEQUITUR Screen Editor Commands. 



1, Delete left portion of object 

2, Delete entire object 

3, Delete right portion of object 

4, Flips "insert" toaoie 

5, Shows rows marked for deletion 
Flip "paoe-taol®" display style 

7, goto «-tb object 

8. Goto last object 

9. 'festores more recent version of row 

10, Display earlier version of row 

11. Executes a command 

12. Search forward for column entry 

13, Search backwards for column entry 

14, Edit card display 



The screen editor commands are used to make actual 
changes (additions, modifications, or deletions) to the 
displayed table on the screen. Table E.3 lists these 
commands which are used in conjunction with the cursor 
object and movement commands listed previously. 
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Additionally there are a number of miscellaneous 
commands that are provided to aid the user. These are listed 
in Table F.4. 



Table F.4 - Additional SEQUITUR Commands 



1. Get Edit Helo 
n. Scroll Forward 

3, Scroll 3ac'<ward5 

4, Interruot Present Operation 

5, TjOCk/Unloc'<' Cursor Object 



There are an abundance of table tyoes In SEQUITUR. 

’’Virtual" tables consist of pointers to data in a "base" 

* 

table(s’), and are formed by conducting relational operations 
(e.o, JOIN! on the base table(s). Virtual tables are 
permanent additions to the database. All ooeratlcns 
conducted on the virtual table effect the base table, but 
not all operations on the base table will reflected in the 
virtual table, 

"Slice" tables consist of the data from a "home" table, 
and are formed by restricting or rearranolng the columns In 
the home table. Actually, slice tables are just alternate 
ways of viewing the same home table. All ooeratlcns 

conducted on the slice table effect the home table, and all 
operations on the home table effect the slice table. 
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"Template" tables are used to store control information 
on the operationCs) (SELECT, SORT, UNION, DUPLICATE, UNIQUE, 
INTERSECTION, and DIFFERENCE) desired to be oerformed on a 
set of "base" tables. The user specifies once the sequence 
of operations to be oerformed, and each time that result is 
desired the appropriate template table is called to create 
the desired virtual table, 

' SEQUITUR orovtdes several methods of outputting data to 
the user: 

(1) There is the "orlnt" command which oromots the user 
to specify heading, page length, margins, cage number, date, 
column/rov divider symbol, etc, for either a "table" or 
"oaoe" style output. The entire table is then outout, one 
record at a time, in the soeclfied format. 

(2) There is the "form generator". The user creates a 
form letter or document by making an entry in the "forms" 
table in either "pace" or "table" style, and answering 
several system prompts as to page size, width, margins. The 
form generator is intended for letter type generation since 
it only allows one text field in the form. All other entries 
are pulled from an appropriate table and the "form" repeated 
for each row in that table. 

(3) There is the "report generator". The user creates a 
report table that is associated with a known data table. The 
report table specifies which data table columns are to be 
used, how thev are positioned, what name they have on the 
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form, allotted width, and alignment. Again, the user must 
specify formatting items like page length, line length, 
margins, delimiters, and other related items. The Individual 
columns in the report table can be marked for sorting, 
grouping, and/or arithmetic processing. If arithmetic 
processing is opted for, then another table, the '♦function" 
table is created to record what is to be done to each column 
- total, minimum, maximum, average, or count. 

Based on a very short familiarization exserlence with 
SEOUITUP there is no doubt that it is a powerful and 
complete relational DBMS, However, it is not as user 
friendly as its advertisements would lead you to believe. 
Some of the problems encountered were; 

Cn Too many commands to remember. This increased 
learning time and added to the confusion. Too many of the 
commands were just window dressing in that their effect 
could have be done using other commands, (Like the "Object 

extra cursor movement and deletion commands.) wniie 
using keys as commands leads to faster co'^mand Inout, it 
makes things more difficult when there are so many commands 
the symbol on the key has little or no relation to Its 
effect . 

C2) The structure of the user Interface was unwieldy. It 
was easy to get lost and difficult to recover to a known 
location, Ooeratlons that worked under one condition did 
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not work in another, or produced completely different and 
unexpected results, (e.g, in some Instances the "execute" 
command will return you to the main menu, in others It was 
lonored or treated as a mistake,) 

(3) There were too many tvoes of tables, ways of using 
tables, editing tables, and creating relations between 
tables. The user is being swamoed with a level of detail 
that is better left to the system. It seems that SEOUITUR 
was created with simDllcity and user suooort being lesser 
considerations to system sophistication. 
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APPENDIX G; VISICALC 



VISICALC Is an electronic spreadsheet proqram created by 
Software Arts, Inc, of Cambridge, Massachusetts and marketed 
by Personal Software Inc. of Sunnvvaie, CA, Its purpose Is 
to allow the user to easily model a wide ranae of numerical 
problems In a standard tabular format by replacing the 
user's oencll, calculator, and scratchpad. 

The screen is divided into a arid of columns and rows 
that form addressable (column, row) entry oosltions. The 
columns, which run across the top of the grid, are lettered 
starting with "A'* and the rows, which run down the side, are 
numbered starting with "1", Each entry position is an 
Indeoendent entity, and can contain a character string, a 
numeric value, or a function that must be calculated. Entry 
oosltions that contain functions are recalculated by 
VISICALC each time certain conditions are met. The functions 
will specify values In terms of constants, operators, and 
the values of other entry positions. 

The screen Is used as a "window" into the spreadsheet 
and Is modifiable by the user. The user is given numerous 
commands, see Table G.l, with which to alter the disolay 
format of the screen. 
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Table G,1 - VISICALC Display Commands 



1, Clear Spread Sheet 

2, Set Global Display Format To; 

- Tnteoer 

- Dollars & Cents 

- Left/Right Justified 

- Graph 

3, Set Entry Display Format To; 

- Integer 

- Dollars St Cents 

- Left/Right Justified 

- Graph 

4, Reset Entry To Global Display Format 

5, Set Column width Within A window 
5, Set Order Of Recalculation; 

- Column wise 
-Rowwise 

7, Set Recalculation; 

- Automatic 

- Manual 

3. Move An Entire Row Or Column 
R, Window Control; 

- Split Screen Horizontal 

- Split Screen Vertical 

- Single Window 

10, window Synchronization; 

- Synchronized 

" Dnsynchronlzed 



The window can be "split" into two halves so as to looK 
into nonadjoining areas of the soread-sheet simultaneously. 
The two windows can be "synchronized" so they move together# 
or unsynchronized sc movement is independent. Display 
format may be globally set for the screen as a whole, or 
Individual entry positions can be assigned their own format. 
Column width is variable from 3 to 37, but columns in the 
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same window must have the same width. The value of each 



entry position is calculated by "column order" (Ai, A2, 

An, Bi, B2, Bn, f!l , etc,) unless the user changes the 

recalculation order to "row order" (Ai, Bl, ,,,, nl, A2, B2, 
n2, C2, etc,). By default VISICALC starts in 

"automatic" recalculation mode where the value of all entry 
positions are recalculated each time an entry is changed. As 
this can significantly slow down the model when laroe grids 
ard/or comolicated numerical exoresslons are used, the user 
can enter "manual" recalculation mode where a command must 
be Issued to cause recalculation to occur, 

VISICALC orovldes a command-line oriented editor that 
enters, modifies, or deletes data In a referenced entry 
Dosltion(s). A cursor is orovided on the grid to indicate 
the current entry position referenced by VISICALC, There 
are screen commands to allow the user to scroll across the 
grid or to move to an exact (row, column) entrv position. 
If needed, the numeric Processing capability of VISICALC can 
be used like a calculator to support the user's 
computational needs, A powerful capability of VISICALC is 
the replicate command. This allows the user to define an 
entry once, and then have it entered in a range of 
successive column or row entry positions. Additionally, the 
user can specify if the original entry is to be replicated 
exactly, or should any references to other entry positions 
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be updated at each new position to take Into account 



relative position on the spreadsheet. 



Table G,2 - VISICALC Cursor Movement & Entry Commands, 



11, Move Cursor Right Or Up 

12, Move Cursor Left Or Down 

13, Change Cursor Direction; 

- Up/Down 

- '?laht/Left 

14, Move Cursor To The Other Window 

15 , Move Cursor To A Specific Entry Position 



16, 

17, 

1 «. 

19, 

20 , 
21 , 



22 , 

23, 

24, 

25, 

26, 



Abort Last Command 

set An Entry Position To Blank 

Delete An Entire Pow Or Column 

Inset A New Row Or Column 

Replicate An Entry 

Set Title Areas; 

- Horizontal Title 

- Vertical Title 

- No Title 

Reoeat A Label Entry 

Make An immediate Numerical Calculation 
Enter A Label In An Entry Position 
Enter A Value In An Entry Position 
save A Copv Of The Soread-Sheet 



Since VISICALC is a numerical modeling tool it has a 
series of arithmetic and aoaregate functions that it 
supports. Table G,3 provides a listing, VISICALC has been 
designed to store numbers in decimal format, not binary, and 
maintains them with uo to eleven significant digits or 
decimal olaces. 
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Table G.3 - VISICALC Arithmetic & Aggregate Functions 



a. Addition 

b. Subtraction 

c. MultlDllcatlon 

d. Division 

e. Exponentiation 

f. Calculate The Sum 0£ A Range Of values 

0. Calculate The Minimum In A Ranae Of Values 
h. Calculate The Maximum In A Ranoe Of Values 

1. Count The Number Of Entries In A List 

1, Calculate The Average Of A Ranae Of Values 
X, Calculate The Net-Present-Value Of A 
Range Of Values 

l, Perform A Lookuo Ooeratlon 

m. PI (3.1415956536) 

n. Calculate The Absolute Value 

0 , Calculate The Integer Portion Of A Value 

o, Sauare Root 

g. Logarithms, Base 7 

r. Logarithms, Base 10 

s, Tr loonometr ic Functions (Sin, Cos, Tan, Asln, 

Acos, Atan) 



VISICALC makes use of dynamic memory allocation so the 
actual dimensions of the spread-sheet deoend on the amount 
of memory available and the complexity of the entries made 
by the user. The user does not have to worry about memory 
allocation since VISICALC takes responsibility for its use 
and efficiency. As entries shrink, or are deleted, VISICALC 
reclaims the extra memory space. The user is shown how much 
memory remains and a warning oromot occurs when memory space 
is nearly exhausted. 
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For a permanent copy of the contents of the spread sheet 
the user may send the output to a printer, A suboart of the 
total spread-sheet may be sent by designating the lower 
right corner to be printed, 

VISICALC Is a powerful and fairly simple modeling tool 
whose advantages seem to easily outweigh the disadvantages. 
The command vocabulary is low C?6 commands, 1'^ functions) 
and the greater majority are actually useful and not just 
window dressing. The user manual is well written and easily 
understood, but is fairly lono, VisiCALC supoorts a Known 
human weakness (small/fast short term memory, large/slow 
long term memorv, and slow calculation speed) bv rememberina 
t^e details of a commonly recccurring user problem (nne 
situation to be modeled), limiting the user to orovlding a 
smaller and more select set of Initial Incuts, and 
performing the computations in a faster, more reliable, and 
repeatable manner. However it does have some problems: 

(1) Command strings and their effect must be memorized 
since there Is little relation to the string and the effect. 
Menus provided by the system are very poor, and reguire you 
to already Know the meaning of the command string. 

C2) A basic understanding of VISICALC and a high degree 
of operational caoablllty can be obtained, in a fairly short 
time, by reading only the first third of the user manual. 
However, to gain maximum use of the system regulres a 
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significant amount of time and effort to read the entire 
user manual and experiment with the operations. Some nice to 
Know features that have a major effect on model validity 
(e,g, recalculation order) are discussed at the end of the 
user manual and might be easily missed. 
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APPENDIX H: ZIP 



The relational data base management system "DBASE II"^ 
described In Apoendix (D), contains a set of commands which, 
when embedded In a "command" file, define the output format 
used to generate the display on the screen, or outout to the 
printer. In addition to generating the disolay form, the 
commands also direct the DBASE II system to either determine 
the values of the entries from a record In the referenced 
database, or from memory variables. If the inout device Is 
the screen/Keyboard , DBASE II may retrieve a user entered 
value from the screen and store it In a field of a database 
record, or in a memory variable. These form definition 
commands can also be out Irro a new tyoe of file, the 
"format" file, by ZIP, In this case the format, contained 
In the "format" file. Is used as an display overlay to 
prompt the user to change data values In an existlnc record 
In a "database" file. 

ZIP Is a CP/M program used to generate, or modify, a 
DBASE II "command" or "format" file. It is a powerful tool 
in the sense that the user is not required to know the 
details of the DBASE II form generation caoabillty 
("command" files, and display commands). ZIP presents the 
user with a blank screen and an on-screen editor, which 
supports several levels of cursor movement and formatting 
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commands, to help In the form design. Table H,1 lists the 
ZIP editor commands. 



Table H.l - ZIP Editor Commands, 



1 , 



2 . 

3 , 

4 , 

5 , 



6 . 

7 . 

3 . 

o 

10 . 



11 , 



Screen commands 

- too 

- bottom 

• 

- orevlous 

- first 

- last 

Middle of line 
Insert a space 
Add a line 
helete 

- character 

- 1 Ine 

Draw/Erase horizontal line 
Draw/Erase vertical line 
Erase/Save wor'c file 
Insert DSASE II command expression 
Chance variable 

- vertical mariner 

- horizontal marker 

- tab spacing 

- margin 

- page length 
oult 



The cursor can be moved to any position on the blank screen 
where the user will enter the Information recuired by the 
ZIP program. Information is conveniently limited to literal 
strings, memory variables, record field values, and fetching 
a value from the screen and storing it into a record field 
or memory va'rlable. Interspersed between these ZIP 
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formattlnq commands may be DBASE II executable commands if 
the tile tyoe Is "command". There are special purpose 
commands to draw, or undraw, vertical and horizontal lines 
on the form. 

The ZIP program mav be viewed as a translator between 
the screen design made by the user and the operations of 
DBASE II, The screen contents associated with each screen 
position are translated into a seouence of DBASE II 
commands, statements, and control structures which are 
organized as either a "command" or "format" file, ZIP also 
places any embedded execution commands into the file and 
automatically sets, or resets, the aoDroorlate system 
"toooles" as needed. 

ZIP is a useful support tool for DBASE II in that it 
relieves the user from having to program a "command" file in 
order to create a desired display format. However, It must 
be pointed out that ZIP Is a very basic formatter, is line 
oriented, and is Incapable of the more comolex types of 
displays , 
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APPENDIX IS MAIL 



"MAIL" is an electronic mall facility produced by the 

University of California at Berkeley and Bell Laboratories 

for the UNIX oceratlno system. It allows users to send 

rressaoes to other users, or groups of users, on the system. 

The basic unit of the mail system is the message, which 

Is simply a special tyoe of text file. The messaae is 

preformatted and contains fields for originator, 

destination, subject, copy to, and body , Messages are 

contained either in the users "private" mailbox or In the 

"system" mailbox, A "dead-letter" file is also maintained 

for each user to contain messaa^s which cannot be delivered 
» 

to a valid destination. The private mailbox and dead-letter 
file are maintained as text files in the UNIX directory and 
therefore can be used by other programs running under UNIX. 

Upon logging into the Unix system, a prompt appears at 
the terminal Indicating that there is mail for the user. 
Messages addressed to a user are initially contained in the 
system mailbox, and can be read frem the system mailbox by 
the MAIL facility. The messaaes already in the private 
mailbox and/or dead-letter file are text flies and thus not 
directly accessible to the MAIL facility. 

The user may elect to read the mail by invoking the MAIL 
facility, A one line summary of all messages in the system 
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mailbox Is presented to the user, and each message Is given 
an Integer identification number starting at one. At this 
point the user has a number of different options available 
as summarized in Table I.l. 



Table I.l ■ MAIL Command Summary 



I. Alias a name + 

7 , Unalias a name(s) 

3, Goto previous message * + 

4, Goto next message * 

5, Display summary of commands + 

6, Display out all currently defined aliases 

7, Disolay a message 

3, Display out headers of message list + 

9, Display message list 

10, Disolay size of each message 

II, Display top few lines of each message 

12, Execute the following UMIX shall command 

13, Change directory 

14, Delete messaoeCs) + 

15, Delete current message, Print next message 

16, Undelete messages mar!<ed for deletion 

17, 9eplv to a received message ♦ 

IS, Edit a list of messages In turn 

19, Send message to desicnated users + 

20, End-of-message + 

21, Exit, don't change system mailbox ♦ 

22, Quit, save undeleted or unsaved messages in the 

user's mailbox, save unreferenced in the 
system mailbox. 

23, Marx message(s) to be saved in system mailbox * 

24, Save a message list by appending to a text file * 

25, List current range of message headers 

26, Help + 

27, Set options m 

28, Unset options 



♦ MAIL facility has more than one command to 
perform this action, 

♦ Useful - see page 170, paragraph (2), 
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The user may select a message and read it. After 
reviewing the message the user may forget the message, save 
it in the system mailbox, delete it, or oreoare a response. 
When the user aults the MAIL facility all messages which 
have not been deleted, saved, or reviewed are placed bac?c 
Into the system mailbox. The remaining messages, those 
reviewed but no soectal action indicated, are placed in the 
private mailbox. If the user desires, the vail facility can 
be exited and the system mailbox left unchanged. 
Additionally the user can create "alias" names that 
correspond to multiple users, ask for message summaries, 
aopend messages to files, or invoke an editor. 

The mail utility does not contain its own editor, but 
depends on the editcrCs) available to the UNIX system and on 
the user to set an option soecifylng wnlch one is desired. 
When the user indicates that a message is to be created, the 
editor is invoked, the user enters the text, and when 
finished issues an end-of-message command to return control 
to the VAIL facility, while in the editor, the user can 
issue "escape" commands that directly effect the messaae 
processing, A listing of these escape commands is provided 
in Table 1,2. Contents of other files may be inserted into 
the message, names of recipients added or changed, the 
header field edited, or an alternate editor invoked. 
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Table 1,2 - MAIL escape commands 



1, Execute UNIX shell command 

2, Add names to recipients of copy 

3, Read "deadletter" file into message 

4, Invoke text editor 

5, Abort the message being sent 

6, Insert a named file into the message 

7, Create a subject field 

A, Write the message into a named file 

°ipe the message through a process as a filter 
10. Insert a string into the message 



+ Useful - see page 170, paragraph (2D, 



While In the wail facility, UNIX shell commands may be 
Issued, The mail facility Is temporarily Interrupted, the 
command is executed, and then the "^ail facility !s resumed 
without adverse effect. 



Table 1,3 - MAIL ootlons. 



1, ( Append/Prepended) messages to private mailbox 

2, (Yes/No) subject line prompt 

3, (Yes/No) Prompt for carbon copy recipients of message 

4, (Yes/No) Modify delete command 

5, (Yes/No) Ignore terminal Interruot signals 

6, (Yes/No) Include sender In group message recipients 

7, (Yes/No) Saving Interrupted messages 

8, Define default editor name 

9, Define escape character 

10, Define file to record outgoing mail 

11, Define number of lines In the "top” of a message 
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Additionally, the MAIL facility has a series of options 
the user can change to tailor its operation. Table 1,3 
provides a listing of these options. 

The MAIL facility is a good support Program and is gulte 
capable of accomplishing its coals. However, it has more 
than its fair share of problems, 

(1) There is a very limited user manual, and experience 
must be gained from other users or by trial and error. 

(?) There are too many commands, and too many of those 
duplicate each other. The number of commonly useful 
commands is low (martced with a +), with the rest being 
window-dressing, 

(3) The facility is not user friendly. The user must be 
aware of location in the facility and wnat is exnected next, 
because there are no special prompts and the help command 
only provides a command summary. 

(4 ) If the message recipient is on line when the message 
arrives, whatever operation is in progress is rudely 
Interrupted bv the display of the message. This can be very 
disconcerting to the recipient. 

(5) The user can't determine which message is going 
where (system mailbox, private mailbox, dead-letter file), 
prior to leaving the mail facility. 
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